Terms of Service

The Gist

We (the folks at Automattic) are on a mission to make the web a better place. We hope you love our products and services — from website publishing tools to ecommerce solutions to security backup systems to management tools for global companies to the next great idea that we havenât even thought of yet â as much as we love creating them.

These Terms of Service (âTermsâ) describe our commitments to you, and your rights and responsibilities when using our services. Please read them carefully and reach out to us if you have any questions.

Weâve decided to make these Terms available under a Creative Commons Sharealike license. You can grab a copy of these Terms and other legal documents on Github. Youâre more than welcome to copy them, adapt them, and repurpose them for your own use. Just make sure to revise the language so that your Terms reflect your actual practices. Also, if you do use these Terms, weâd appreciate a credit and link to Automattic somewhere on your website.

Terms of Service

These Terms govern your access to and use of WordPress.com, Jetpack.com, VaultPress.com, and Happy.Tools, as well as all content and Automattic products and services (for example, ecommerce services as outlined below in Section 7e) available at or though these websites (collectively, âServicesâ).

These Terms also govern visitorsâ access to and use of any websites that use our Services, such as websites hosted on WordPress.com that are operated by our users.
For some of Automatticâs other products and services, such as WooCommerce, Akismet, CrowdSignal, and WordPress.com VIP, additional Terms of Service may apply and will be posted on the websites for those products and services.

Our Services are offered subject to your acceptance, without modification, of all of the terms and conditions contained herein and all other operating rules, policies (including, without limitation, Automatticâs Privacy Policy), and procedures that may be published from time to time by Automattic (collectively, the âAgreementâ). You agree that we may automatically upgrade our Services, and the Agreement will apply to any upgrades.

Please read the Agreement carefully before accessing or using our Services. By accessing or using any part of our Services, you agree to become bound by the Agreement. If you do not agree to all the terms of the Agreement, then you may not access or use our Services.

1. Whoâs Who

Throughout these Terms, âyouâ applies to both individuals and entities that access or use our Services. If you are an individual using our Services on behalf of an entity, you represent and warrant that you have the authority to bind that entity to the Agreement and that by using our Service(s), you are accepting the Agreement on behalf of that entity.

We use the term âDesignated Countriesâ to refer to Australia, Canada, Japan, Mexico, New Zealand, and all countries located in the European continent. If you reside in the âDesignated Countries,â your Agreement is with Aut OâMattic A8C Ireland Ltd. If you reside outside of the âDesignated Countries,â your Agreement is with Automattic Inc.

We refer to Aut OâMattic A8C Ireland Ltd. and Automattic Inc. collectively as âAutomatticâ or âweâ throughout these Terms.

2. Your Account

Where use of our Services requires an account, you agree to provide us with complete and accurate information when you register for an account. You will be solely responsible and liable for any activity that occurs under your username. You are responsible for keeping your account information up-to-date and for keeping your password secure.

You are responsible for maintaining the security of your account and any Service-related website, store, or other content, and you are fully responsible for all activities that occur under your account and any other actions taken in connection with our Services. You shall not share or misuse your access credentials. You must immediately notify us of any unauthorized uses of your account, store, or website, or of any other breach of security. We will not be liable for any acts or omissions by you, including any damages of any kind incurred as a result of such acts or omissions.

3. Minimum Age Requirements

Our Services are not directed to children. Access to and use of our Services is only for those over the age of 13 (or 16 in the European Union). If you are younger than this, you may not register for or use our Services. Any person who registers as a user or provides their personal information to our Services represents that they are 13 years of age or older (or 16 years or older in the European Union).

4. Responsibility of Visitors and Users

We have not reviewed, and cannot review, all of the content (such as, but not limited to, text, photo, video, audio, code, computer software, items for sale, or other materials) posted to our Services by users or anyone else (âContentâ) and are not responsible for any use or effects of such Content. So, for example:

We do not endorse any Content or represent that Content is accurate, useful, or non-harmful. Content could be offensive, indecent, or objectionable; include technical inaccuracies, typographical mistakes, or other errors; or violate or infringe the privacy, publicity rights, intellectual property rights (see our Copyright Infringement and DMCA Policy section to submit copyright complaints), or other proprietary rights of third parties.
If you post Content, comment on a website, or otherwise make (or allow any third party to make) Content available on our Services, you are entirely responsible for the Content, and any harm resulting from, that Content or your conduct.
We disclaim any responsibility for any harm resulting from anyoneâs use, purchase, or downloading of Content. If you access or use any Content, you are responsible for taking precautions as necessary to protect yourself and your computer systems from viruses, worms, Trojan horses, and other harmful or destructive content.
Any Content offered for sale through any of our Services are the sellerâs sole responsibility, and you agree that you will look solely to the seller for any damages that result from your purchase or use of Content.
We are not a party to, and will have no responsibility or liability for, any communications, transactions, interactions, or disputes between you and the provider of any Content.
Please note that additional third party terms and conditions may apply to the downloading, copying, purchase, or use of Content.

We also have not reviewed, and cannot review, all of the material, including computer software, made available through the websites and web pages that link to, or are linked from, WordPress.com or our other Services. For example:

We do not have any control over those websites and are not responsible for their contents or their use.
The existence of a link to or from one of our Services does not represent or imply that we endorse such website.
You are responsible for taking precautions as necessary to protect yourself and your computer systems from viruses, worms, Trojan horses, and other harmful or destructive content.
We disclaim any responsibility for any harm resulting from non-Automattic websites.

5. Fees, Payment, and Renewal

Fees. Some of our Services are offered for a fee â such as Jetpack, and VaultPress, and Happy Tools – while other Services may be free with optional paid upgrades, such as a WordPress.com plan (collectively, âPaid Servicesâ). By using a Paid Service, you agree to pay the specified fees. Depending on the Paid Service, there may be a one-time fee or recurring fees. For recurring fees, weâll bill or charge you for in regular intervals (such as monthly, annually, or biennially), on a pre-pay basis until you cancel, which you can do at any time by contacting the relevant support team.

Taxes. To the extent permitted by law, or unless explicitly stated otherwise, all fees are exclusive of applicable federal, provincial, state, local or other governmental sales, goods and services, harmonized or other taxes, fees, or charges now in force or enacted in the future (âTaxesâ). You are responsible for payment of all applicable Taxes relating to your use of our Services, your payments, or your purchases. If we are obligated to pay or collect Taxes on the Fees youâve paid or will pay, you are responsible for such Taxes, and we may collect payment for such Taxes.

Payment. If your payment fails or Paid Services are otherwise not paid for on time, we may immediately cancel or revoke your access to the Paid Services. If you contact your bank or credit card company to decline or reverse the charge of fees for Paid Services, we may revoke your access to our Services in general.

Automatic Renewal. To ensure uninterrupted service, recurring Paid Services are automatically renewed. This means that unless you cancel a Paid Service before the end of the applicable subscription period, it will automatically renew, and you authorize us to invoice you or use any payment mechanism we have on record for you to collect the then-applicable subscription fee (as well as any Taxes). Your Paid Services are renewed for the same interval of time. For example, if you purchase a WordPress.com annual plan, you will be charged each year.

Refunds. While you may cancel a Paid Service at any time, refunds are issued in our sole discretion, unless otherwise required by applicable law.

Fee Changes. We may change our fees at any time. When applicable, we may give you advance notice of the fee changes. If you donât agree with the fee changes, you can cancel your Paid Service.

6. General Representation and Warranty

You represent and warrant that your use of our Services:

Will be in strict accordance with these Terms;
Will comply with all applicable laws and regulations (including, without limitation, all applicable laws regarding online conduct and acceptable content, privacy, data protection, and the transmission of technical data exported from the United States or the country in which you reside);
Will not use the Services for any unlawful purposes, to publish illegal content, or in furtherance of illegal activities;
Will not infringe or misappropriate the intellectual property rights of any third party;
Will not overburden Automatticâs systems, as determined by us in our sole discretion;
Will not disclose sensitive personal information of others;
Will not be used to send spam or bulk unsolicited messages;
Will not interfere with, disrupt, or attack any service or network; and
Will not be used to create, distribute, or enable material that is – or that facilitates or operates in conjunction with – malware, spyware, adware, or other malicious programs or code.

7. Specific Service Terms

a. WordPress.com Websites and Accounts

WordPress.com enables you to create beautiful websites and blogs, and we would love for you to use it. A WordPress.com account also allows you to sign into some of our Services.

WordPress.comâs basic service is free, and we offer paid plans for advanced features such as a custom domain name, extra storage, and access to premium themes. Our service is designed to give you as much control and ownership over what goes on your website as possible and encourage you to express yourself freely. However, be responsible in what you publish. In particular, make sure that none of the prohibited items (like spam, viruses, or serious threats of violence) appear on your website.

If you find a WordPress.com website that you believe violates these Terms, please visit our dispute resolution and reporting page.

Your WordPress.com Website. If you create a website on WordPress.com, you get to use an Automattic-owned subdomain, such as example.wordpress.com or mollys.food.blog. You must not engage in âdomain squatting,â claim an unreasonable number of subdomains (as determined by us), or sell access to any subdomains.

License. By submitting Content to Automattic for inclusion on your website, you grant Automattic a world-wide, royalty-free, and non-exclusive license to reproduce, modify, adapt, and publish the Content solely for the purpose of displaying, distributing, and promoting your website. This license also allows Automattic to make any publicly-posted Content available to third parties selected by Automattic (through Firehose, for example) so that these third parties can analyze and distribute (but not publicly display) the Content through their services. You also give other WordPress.com users permission to share your Content on other WordPress.com websites and add their own Content to it (aka to âreblogâ your Content), so long as they use only a portion of your post and they give you credit as the original author by linking back to your website (the reblogging function on WordPress.com does this automatically!).

Removing Content. If you delete Content, we will use reasonable efforts to remove it from public view (or in the case of a private website, from view by the authorized visitors) on WordPress.com, but you acknowledge that caching or references to the Content may not be made immediately unavailable.

Web Traffic. We use a third party, comScore, Inc. (âcomScoreâ), to measure WordPress.comâs audience and usage. By hosting your website on WordPress.com, you agree to assign the traffic relating to your website to Automattic and authorize us to sign a Traffic Assignment Letter on your behalf for comScore audience measurement reports. Your websiteâs traffic will be included under Automattic. You understand that your website will not receive credit for traffic in these reports, and you must not assign your websiteâs traffic to any other party. If we or comScore require additional documentation to verify ownership of your website or domain name, you agree to make reasonable efforts to accommodate such requests.

Prohibited Uses. By using WordPress.com, you represent and warrant that your Content and conduct do not violate the User Guidelines.

HTTPS. We offer free HTTPS on all WordPress.com websites by default, including those using custom domains, via Letâs Encrypt. By signing up and using a custom domain on WordPress.com, you authorize us to act on the domain name registrantâs behalf (by requesting the necessary certificates, for example) for the sole purpose of providing HTTPS on your website.

Advertisements. We reserve the right to display advertisements on your website unless you have purchased a plan that includes the removal of ads.

Attribution. We reserve the right to display attribution text or links in your website footer or toolbar, attributing WordPress.com or the theme author, for example. Some of these attributions may not be altered or removed. For more details about what these attributions might look like, and under which circumstances (if any) they may be altered or removed, please see our Admin and Action Bars support page.

Friends of WP.com Themes. By activating a partner theme from the Friends of WP.com section of our themes directory, you agree to that partnerâs terms of service. You can decline the terms of service at any time by deactivating the partner theme.

Domain Names. We act as a registrar and also work with third party registrars in order to provide our users with domain name services. When you register or renew a domain name on WordPress.com, or when you transfer an existing domain name to WordPress.com, you become bound by the relevant registrarâs terms and conditions, either the Automattic Domain Name Registration Agreement, Tucows Domain Inc. Registration Agreement, or this Domain Name Registration Agreement, in addition to these Terms. Which registrar terms apply depends on the top-level domain (TLD) you choose, and in some cases, the date you register your domain, so please see this table that outlines all of the TLDs we offer and the applicable registration agreement to determine which agreement(s) apply to you. These registrar terms are incorporated by reference into these Terms.

Further, your use of the domain name is also subject to the policies of the Internet Corporation for Assigned Names and Numbers (âICANNâ). You can read about your rights and responsibilities as a domain name registrant under ICANNâs Registrar Accreditation Agreement and about domain name registration generally.

For details about what happens during the domain expiration process, and how we may notify you of domain expiration, please see the Domain Expiration support page.

Please refer to the domain pricing and available TLDs page for details about fees associated with domain registrations, renewals, and redemptions.

b. Jetpack

Jetpack is a plugin that connects your self-hosted WordPress website to WordPress.comâs infrastructure to give you powerful WordPress.com features.

Jetpack Content. Youâre fully responsible for the content of any website you own that runs Jetpack (âJetpack Contentâ).

Features. Jetpack includes various features, and you can visit Jetpack.com to learn more about them. Some features, like Enhanced Distribution, when activated, will include your Jetpack Content in Firehose. By activating these features, you grant us permission to display your Jetpack Content on WordPress.com for the purpose of distributing and promoting your website. Some features are on by default and others you need to enable manually. You can see which features are active, and activate and deactivate features, on your dashboard.

License. You agree that we may scan your website, and compile aggregated/anonymized statistics for our internal use to optimize Jetpackâs performance. By submitting Content to Automattic for inclusion on your website, you grant Automattic a world-wide, royalty-free, and non-exclusive license to reproduce, modify, adapt, and publish the Content solely for the purpose of displaying, distributing, and promoting your website. This license also allows Automattic to make any publicly-posted Content available to third parties selected by Automattic (through Firehose, for example) so that these third parties can analyze and distribute (but not publicly display) the Content through their services.

Storage of Information. Certain Jetpack features rely on WordPress.com servers to function, such as those that allow you to send email, publish links, relate posts to each other, or resize images. To take advantage of the performance boosting features of Jetpack, certain information about the Content, settings, and setup of your website are synced with our servers, as described on our What Data Does Jetpack Sync? support page.

Prohibited Uses. Your website and Jetpack Content must comply with Jetpackâs Service Guidelines.

c. VaultPress

VaultPress is a subscription-based security and backup service for self-hosted WordPress websites.

VaultPress Content. VaultPress will backup your WordPress content (e.g., your WordPress database, plugins, themes, and uploads, as well as some additional files, as described in this introduction to VaultPress) (âVaultPress Contentâ). You can view the Content that VaultPress backs up via your VaultPress dashboard. Youâre fully responsible for your VaultPress Content. Itâs your responsibility to ensure that your websiteâs Content abides by applicable laws and by these Terms. We donât actively review the VaultPress Content.

Access. If you lose access to your WordPress.com account, you may not be able to access your backed up VaultPress Content.

License. By using VaultPress, you grant us access to your websiteâs servers for the purpose of backing up and securing your VaultPress Content, and restoring files and database information (which may include access details for multiple servers or accounts for each website that we backup). In order to address security vulnerabilities, we may push an upgrade to your website, or we may access your website to remove malicious code. We may also scan VaultPress Content and compile aggregated/anonymized statistics for our internal use to optimize the performance of the VaultPress service. You also grant us a worldwide, royalty-free, and non-exclusive license to copy and store your VaultPress Content, to the extent necessary to operate the VaultPress service. These Terms donât give us any rights in your VaultPress Content, beyond those we need to operate VaultPress. You own your VaultPress Content.

Cancellation. If you cancel your subscription to VaultPress, we will queue your backed-up VaultPress Content for deletion.

d. Happy Tools

Happy Tools is a suite of software and consulting services to help modern and distributed companies manage, grow, and support their business.

Prohibited Uses. You agree not to:

Modify, decompile, reverse engineer or otherwise alter or seek to derive the trade secrets and other inherent intellectual property of Happy Tools; or
License, sublicense, sell, resell, rent, lease, transfer, assign, distribute, or otherwise commercially exploit or make Happy Tools available to any third party, other than your authorized users.

e. Ecommerce Services

There are certain features offered via WooCommerce, WooCommerce Services, or WordPress.com that enable you to sell items (goods, content, services, etc.) on your website (âEcommerce Servicesâ). If you use WooCommerce, the WooCommerce Use Terms also apply.

Usage of Information. WooCommerce Services may require Automatticâs servers, a connection to our partners, and/or data from your website, to work, as described on our What Data Does Jetpack Sync? support page.

Prohibited Uses. If your store is on WordPress.com, you must not violate our User Guidelines or Store Guidelines.

Third Party Services. You may choose to set up and/or use third party services, such Stripe or PayPal to collect payment, TaxJar to calculate taxes, or EasyPost to manage shipping. If you do so, be aware that some of your â and your customersâ â data may be passed to the respective third party, and the respective third partyâs terms of service, privacy policy, and other policies may apply. We are not involved in these relationships. Please note that some of these third party services (like TaxJar) may be enabled by default, but you may disable them before your store is set up. If you do not want to use these third party services, please disable them.

Tax Calculations. Tax calculations are provided by TaxJar. You are responsible for all taxes and fees associated with your ecommerce activities. You must collect, report, and/or pay the correct amounts to the appropriate authorities, if applicable and, if needed, inform your customers about any taxes they may be required to pay and issue appropriate invoices. While some Ecommerce Services allow you to include sales taxes or Value Added Taxes in transactions, you should not rely solely on these features. While our goal is to keep our documents and tools up-to-date, tax laws change rapidly, and we do not guarantee that tax calculations you receive through or in connection with our Services are complete and accurate. Tax laws also differ from jurisdiction to jurisdiction and may be subject to different interpretations by different authorities. We recommend that you consult with a tax professional for your specific tax situation when assessing the correct tax rates you should charge.

Shipping Services. Shipping labels are provided by EasyPost and allow you to take advantage of real-time shipping rates to purchase postage and print shipping labels from certain mailing services, such as USPS and Canada Post. We act only as an intermediary between you and these third parties; we are not involved in any way with your product or its shipment. We also do not warrant that the results you obtain from the use of these services (rates and labels, for example) will be accurate or reliable.

You are solely responsible for compliance with all applicable rules and regulations, including domestic and international shipping and customs regulations and those of the relevant mailing service. For example, if you use USPS postage, you will need to comply with their shipping restrictions and mailing standards, among others.

In addition, you are solely responsible for customs charges, import taxes or duties, or any other charges related to your shipments. If any charges are assessed against us as a result of your use of the shipping services, you will reimburse us for the full amount within 7 days.

You authorize us to charge you for the fees associated with each shipping label you create. Each fee will be charged separately to the payment methods you have provided in your WordPress.com account, which you can view and manage as described the Payment Methods support page. If you have multiple payment methods, you can select which should be used for the shipping label service. If we are unable to collect payment from you for these fees, you will be responsible for payment within 7 days; please contact us to remit payment.

Refunds for unused shipping labels must be requested in your storeâs wp-admin within 30 days of creating the label. Please note that depending on your bank and the third party involved, it may take up to 45 days for your refund to issue. If you havenât received your refund within this time frame, please contact us.
You may not transfer or sell postage and/or shipping labels to a third party.

Your Responsibilities. You are solely responsible for all of your ecommerce activities, including your store, your items, its operation, all applicable taxes and fees, compliance with the Payment Card Industry Data Security Standard (PCI DSS), and compliance with any applicable laws. Among other things, this means that:

You should use your best judgment when setting up your store, operating your store, processing payments, and selling items. For example, you may not want to accept check payments if you are not comfortable sharing your mailing address with a customer, or you may want to publish payment and return policies.
We are not involved in your relationships or transactions with any customer or potential customer.
You are responsible for resolving all support questions, comments, and complaints, including refunds, chargebacks, or pricing questions. You should provide contact information so that customers may contact you with questions or complaints.
You are responsible for delivering items sold to your customers, and for fulfilling all promises, representations, or warranties you make to them in connection with a sale.

8. Copyright Infringement and DMCA Policy

As we ask others to respect our intellectual property rights, we respect the intellectual property rights of others. If you believe that material located on or associated with an Automattic product or service violates your copyright, please notify us in accordance with Automatticâs Digital Millennium Copyright Act (âDMCAâ) Policy. We will respond to all such notices, including as required or appropriate by removing the infringing material or disabling all links to the infringing material. We will terminate a visitorâs access to and use of the website if, under appropriate circumstances, the visitor is determined to be a repeat infringer of the copyrights or other intellectual property rights of Automattic or others. In the case of such termination, we will have no obligation to provide a refund of any amounts previously paid to us.

9. Intellectual Property

The Agreement does not transfer from Automattic to you any Automattic or third party intellectual property, and all right, title, and interest in and to such property will remain (as between the parties) solely with Automattic. Automattic, WordPress, WordPress.com, the WordPress.com logo, and all other trademarks, service marks, graphics, and logos used in connection with WordPress.com or our Services, are trademarks or registered trademarks of Automattic or Automatticâs licensors. Other trademarks, service marks, graphics, and logos used in connection with our Services may be the trademarks of other third parties. Your use of our Services grants you no right or license to reproduce or otherwise use any Automattic or third party trademarks.

10. Third Party Services

In using the Services, you may enable or use services, products, software (like themes or plugins), embeds, or applications developed by a third party or yourself (âThird Party Servicesâ) on your website.

If you use any Third Party Services, you understand that:

Third Party Services are not vetted, endorsed, or controlled by Automattic.
Any use of a Third Party Service is at your own risk, and we shall not be responsible or liable to anyone for Third Party Services.
Your use is solely between you and the respective third party (âThird Partyâ) and will be governed by the Third Partyâs terms and policies. It is your responsibility to review the Third Partyâs terms and policies before using a Third Party Service.
Some Third Party Services may request or require access to your (yours, your visitorsâ, or customersâ) data, for example, via a pixel or cookie. If you use the Third Party Service or grant access, your data will be handled in accordance with the Third Partyâs privacy policy and practices. We do not have control over how a Third Party Service may use your data. You should carefully review Third Party Servicesâ data collection, retention, and use policies and practices before enabling Third Party Services.
Third Party Services may not work appropriately with your website, and we may not be able to provide support for issues caused by any Third Party Services.
If you have questions or concerns about how a Third Party Service operates, or need support, please contact the Third Party directly.

In rare cases, we may at our discretion, suspend, disable, or remove Third Party Services from your account or website.

11. G Suite

If you purchase a G Suite subscription, this section applies. G Suite is provided by Google, and your use of G Suite is subject to Googleâs Terms of Use for the services, which youâll accept prior to using G Suite for the first time. Automattic is an authorized reseller of G Suite, but makes no warranties about the services provided by Google, and disclaims Googleâs liability for any damages arising from our distribution and resale of their services. Google will provide technical support for its services, per its Technical Support Services Guidelines. If youâre a business and purchase G Suite for your WordPress.com website, you represent that you have 749 or fewer staff members.

12. Changes

We are constantly updating our Services and that means sometimes we have to change the legal terms under which our Services are offered. These Terms may only be modified by a written amendment signed by an authorized executive of Automattic, or by the posting by Automattic of a revised version. If we make changes that are material, we will let you know by posting on one of our blogs, or by sending you an email or other communication before the changes take effect. The notice will designate a reasonable period of time after which the new terms will take effect. If you disagree with our changes, then you should stop using our Services within the designated notice period, or once the changes become effective. Your continued use of our Services will be subject to the new terms. However, any dispute that arose before the changes shall be governed by the Terms (including the binding individual arbitration clause) that were in place when the dispute arose.

13. Termination

We may terminate your access to all or any part of our Services at any time, with or without cause, with or without notice, effective immediately. We have the right (though not the obligation) to, in our sole discretion, (i) reclaim your username or websiteâs URL due to prolonged inactivity, (ii) refuse or remove any content that, in our reasonable opinion, violates any Automattic policy or is in any way harmful or objectionable, or (iii) terminate or deny access to and use of any of our Services to any individual or entity for any reason. We will have no obligation to provide a refund of any amounts previously paid.

If you wish to terminate the Agreement or your WordPress.com account, you may simply discontinue using our Services, or, if you are using a paid service, you may cancel at any time, subject to the Fees, Payment, and Renewal section in these Terms.

All provisions of the Agreement which by their nature should survive termination shall survive termination, including, without limitation, ownership provisions, warranty disclaimers, indemnity, and limitations of liability.

14. Disclaimer of Warranties

Our Services are provided âas is.â Automattic and its suppliers and licensors hereby disclaim all warranties of any kind, express or implied, including, without limitation, the warranties of merchantability, fitness for a particular purpose and non-infringement. Neither Automattic, nor its suppliers and licensors, makes any warranty that our Services will be error free or that access thereto will be continuous or uninterrupted. If youâre actually reading this, hereâs a treat. You understand that you download from, or otherwise obtain content or services through, our Services at your own discretion and risk.

15. Jurisdiction and Applicable Law.

Except to the extent any applicable law provides otherwise, the Agreement and any access to or use of our Services will be governed by the laws of the state of California, U.S.A., excluding its conflict of law provisions. The proper venue for any disputes arising out of or relating to the Agreement and any access to or use of our Services will be the state and federal courts located in San Francisco County, California.

16. Arbitration Agreement

Except for claims for injunctive or equitable relief or claims regarding intellectual property rights (which may be brought in any competent court without the posting of a bond), any dispute arising under the Agreement shall be finally settled in accordance with the Comprehensive Arbitration Rules of the Judicial Arbitration and Mediation Service, Inc. (âJAMSâ) by three arbitrators appointed in accordance with such Rules. The arbitration shall take place in San Francisco, California, in the English language and the arbitral decision may be enforced in any court. The prevailing party in any action or proceeding to enforce the Agreement shall be entitled to costs and attorneysâ fees.

17. Limitation of Liability

In no event will Automattic, or its suppliers or licensors, be liable with respect to any subject matter of the Agreement under any contract, negligence, strict liability or other legal or equitable theory for: (i) any special, incidental or consequential damages; (ii) the cost of procurement for substitute products or services; (iii) for interruption of use or loss or corruption of data; or (iv) for any amounts that exceed the fees paid by you to Automattic under the Agreement during the twelve (12) month period prior to the cause of action. Automattic shall have no liability for any failure or delay due to matters beyond their reasonable control. The foregoing shall not apply to the extent prohibited by applicable law.

18. Indemnification

You agree to indemnify and hold harmless Automattic, its contractors, and its licensors, and their respective directors, officers, employees, and agents from and against any and all losses, liabilities, demands, damages, costs, claims, and expenses, including attorneysâ fees, arising out of or related to your use of our Services, including but not limited to your violation of the Agreement, Content that you post, and any ecommerce activities conducted through your or another userâs website.

19. US Economic Sanctions

You expressly represent and warrant that your use of our Services and/or associated services and products is not contrary to applicable U.S. Sanctions. Such use is prohibited, and we reserve the right to terminate accounts or access of those in the event of a breach of this condition.

20. Translation

These Terms were originally written in English (US). We may translate these terms into other languages. In the event of a conflict between a translated version of these Terms and the English version, the English version will control.

21. Miscellaneous

The Agreement constitutes the entire agreement between Automattic and you concerning the subject matter hereof. If any part of the Agreement is held invalid or unenforceable, that part will be construed to reflect the partiesâ original intent, and the remaining portions will remain in full force and effect. A waiver by either party of any term or condition of the Agreement or any breach thereof, in any one instance, will not waive such term or condition or any subsequent breach thereof.

You may assign your rights under the Agreement to any party that consents to, and agrees to be bound by, its terms and conditions; Automattic may assign its rights under the Agreement without condition. The Agreement will be binding upon and will inure to the benefit of the parties, their successors and permitted assigns.

Print friendly version

Change log

Attack of the week: searchable encryption and the ever-expanding leakage function

A few days ago I had the pleasure of hosting Kenny Paterson, who braved snow and historic cold (by Baltimore standards) to come talk to us about encrypted databases.

Kenny’s newest result is with first authors Paul Grubbs, Marie-Sarah LacharitÃ© and Brice MinaudÂ (let’s call it GLMP). It isn’t so much aboutÂ building encrypted databases, as it is about the risks of building themÂ badly. And — for reasons I will get into shortly — there have been a lot of badly-constructed encrypted database schemes going around. What GLMPÂ point out is that this weakness isn’t so much a knock against the authors of those schemes, but rather, an indication that they may just be trying to do the impossible.

Hopefully this is a good enough start to get you drawn in. Which is excellent, because I’m going to need to give you a lot of background.

What’s an “encrypted” database, and why are they a problem?

Databases (both relational and otherwise) are a pretty important part of the computing experience. Modern systems make vast use of databases and their accompanying query technology in order to power just about every software application we depend on.

Because these databases often contain sensitive information, there has been a strong push toÂ secure that data. A key goal is to encrypt the contents of the database, so that a malicious database operator (or a hacker) can’t get access to it if they compromise a single machine. If we lived in a world where security was all that mattered, the encryption part would be pretty easy: database records are, after all, just blobs of data — and we know how to encrypt those. So we could generate a cryptographic key on our local machine, encrypt the data before we upload it to a vulnerable database server, and just keep that key locally on our client computer.

Voila: we’re safe against a database hack!

The problem with this approach is that encrypting the database records leaves us with a database full of opaque, unreadable encrypted junk. Since we have the decryption key on our client, we can decrypt and read those records after we’ve downloaded them. But this approach completely disables one of the most useful features of modern databases: the ability for the database server itself to search (orÂ query) the database for specific records, so that the client doesn’t have to.

Unfortunately, standard encryption borks search capability pretty badly. If I want to search a database for, say, employees whose salary is between $50,000 and $100,000, my database is helpless: all it sees is row after row of encrypted gibberish. In the worst case, the client will have to downloadÂ all of the data rows and search them itself — yuck.

This has led to much wailing and gnashing of teeth in the database community. As a result, many cryptographers (and a distressing number ofÂ non-cryptographers) have tried to fix the problem with “fancier” crypto. This has not gone very well.

It would take me a hundred years to detail all of various solutions that have been put forward. But let me just hit a few of the high points:

Some proposals have suggested usingÂ deterministic encryption to encrypt database records. Deterministic encryption ensures that a given plaintext will always encrypt to a single ciphertext value, at least for a given key.Â This enables exact-match queries: a client can simply encrypt the exact value (“John Smith”) that it’s searching for, and ask the database to identify encrypted rows that match it.
Of course, exact-match queries don’t support more powerful features. Most databases also need to supportÂ range queries. One approach to this is something calledÂ order revealing encryption (or its weaker sibling,Â order preserving encryption). These do exactly what they say they do: they allow the database to compare two encrypted records to determine which plaintext is greater than the other.
Some people have proposed to use trusted hardware to solve these problems in a “simpler” way, but as we like to say in cryptography: if we actually had trusted hardware, nobody would pay our salaries. And, speaking more seriously, even hardware might not stop the leakage-based attacks discussed below.

This summary barely scratches the surface of this problem, and frankly you don’t need to know all the details for the purpose of this blog post.

What youÂ do need to know is that each of the above proposals entails has some degree of “leakage”. Namely, if I’m an attacker who is able to compromise the database, both to see its contentsÂ and to see how it responds when you (a legitimate user) makes a query, then I can learnÂ something about the data being queried.

What some examples of leakage, and what’s a leakage function?

Leakage is a (nearly) unavoidable byproduct of an encrypted database that supports queries. It can happen when the attacker simplyÂ looks at the encrypted data, as she might if she was able to dump the contents of your database and post them on the dark web. But a more powerful type of leakage occursÂ when the attacker is able to compromise your database server and observe the query interaction between legitimate client(s) and your database.

Take deterministic encryption, for instance.

Deterministic encryption has the very useful, but also unpleasant feature that the same plaintextÂ will always encrypt to the same ciphertext. This leads to very obvious types of leakage, in the sense that an attacker can see repeated records in the dataset itself. Extending this to the active setting, if a legitimate client queries on a specific encrypted value, the attacker can see exactly which recordsÂ match the attacker’s encrypted value. She can see how often each value occurs, which gives and indication of what value it might be (e.g.,Â the last name “Smith” is more common than “Azriel”.) All of these vectors leak valuable information to an attacker.

Other systems leak more.Â Order-preserving encryption leaks the exact order of a list of underlying records, because it causes the resulting ciphertexts to have the same order. This is great for searching and sorting, but unfortunately it leaks tons of useful information to an attacker. Indeed, researchers have shown that, in real datasets, an ordering can be combined with knowledge about the record distribution in order to (approximately)Â reconstruct the contents of an encrypted database.

FancierÂ order-revealing encryptionÂ schemes aren’t quite so careless with your confidentiality: they enable the legitimate client to perform range queries, but without leaking the full ordering so trivially. This approach can leakÂ lessÂ information: but a persistent attacker will still learn some data from observing a query and its response — at a minimum, she will learn which rows constitute the response to a query, since the database must pack up the matching records and send them over to the client.

If you’re having trouble visualizing what this last type of leakage might look like, here’s a picture that shows what an attacker might see when a user queries an unencrypted database vs. what the attacker might see with a really “good” encrypted database that supports range queries:

leakage

So the TL;DR here is that many encrypted database schemes have some sort of “leakage”, and this leakage can potentially reveal information about (a) what a client is querying on, and (b) what data is in the actual database.

But surely cryptographers don’t build leaky schemes?

Sometimes the perfect is the enemy of the good.

Cryptographers could spend a million years stressing themselves to death over the practical impact of different types of leakage. They could also try to do things perfectly using expensive techniques like fully-homomorphic encryptionÂ and oblivious RAM — but the results would be highly inefficient. So a common view in the field is researchers shouldÂ do the very best we can, and then carefully explain to users what the risks are.

For example, a real database system might provide the following guarantee:

“Records are opaque. If the user queries for all records BETWEEN some hidden valuesÂ X ANDÂ Y then all the database will learn isÂ the row numbers of the records that match this range, and nothing else.”

This is a pretty awesome guarantee, particularly if you can formalize it and prove that a scheme achieves it. And indeed, this is something that researchers have tried to do. The formalized description is typically achieved by defining something called aÂ leakage function. It might not be possible to prove that a scheme is absolutely private, but we can prove that it only leaks as much as the leakage function allows.

Now, I may be overdoing this slightly, but I want to be very clear about this next part:

Proving your encrypted database protocol is secureÂ with respect to a specific leakage functionÂ does not mean it is safe to use in practice. What it means is that you are punting that questionÂ to the application developer, who is presumed to know how this leakage will affect their dataset and their security needs. Your leakage function and proof simply tell the app developer what information your scheme is (provably) going to protect, and what it won’t.

The obvious problem with this approach is that application developers probably don’t have any idea what’s safe to use either. Helping them to figure this out is one goal of this new GLMPÂ paper and its related work.

So what leaks from these schemes?

GLMP don’t look at a specific encryption scheme. Rather, they ask a more general question: let’s imagine that we can only see that a legitimate user has made a range query — but not what the actual queried range values are. Further, let’s assume we can also see which records the database returns for that query, but not their actual values.

How much does just this information tell us about the contents of the database?

You can see that this is a very limited amount of leakage. Indeed, it is possibly the least amount of leakage you could imagine for any system that supports range queries, and is also efficient. So in one sense, you could say authors are asking a different and much more important question: are any of these encrypted databases actually secure?

The answer is somewhat worrying.

Can you give me a simple, illuminating example?

Let’s say I’m an attacker who has compromised a database, and observes the following two range queries/results from a legitimate client:

Query 1: SELECT * FROM Salaries BETWEEN âï¸ and ð¹Â Â Result 1: (rows 1, 3, 5)
Query 2: SELECT * FROM Salaries BETWEEN ð¨ and ð±Â Â Result 2:Â (rows 1, 43, 3, 5)

Here I’m using the emoji to illustrate that an attacker can’t see the actual values submitted within the range queries — those are protected by the scheme — nor can she see the actual values of the result rows, since the fancy encryption scheme hides all this stuff. All the attacker sees is that a range query came in, and some specific rows were scooped up off disk after running the fancy search protocol.

So what can the attacker learn from the above queries? Surprisingly: quite a bit.

At very minimum, the attacker learns that Query 2 returned all of the same records as Query 1.Â Thus the range of the latter query clearly somewhat overlaps with the range of the former.Â There is an additional record (row 43) that is not within the range of Query 1. That tells us that row 43 must must be either the “next” greater or smaller record than each of rows (1, 3, 5). That’s useful information.

Get enough useful information, it turns out that it starts to add up. In 2016,Â Kellaris, Kollios, Nissim and OâNeillÂ showed that if you know the distribution of the query range endpoints — for example, if you assumed that they were uniformly random — then you can get more than just the order of records. You can reconstruct theÂ exact value of every record in the database.

This result is statistical in nature. If I know that the queries are uniformly random, then I can model how often a given value (say, Age=34 out of a range 1-120) should be responsive to a given random query results. By counting the actual occurrences of a specific row after many such queries, I can guess which rows correlate to specific record values. The more queries I see, the more certain I can be.The KellarisÂ et al. paper shows that this takesÂ $O(N^4~log~N)$ queries, where NÂ is the number of possible values your data can take on (e.g., the ages of your employees, ranging between 1 and 100 would give N=100.) This is assuming an arbitrary dataset. The results get much betterÂ if the database is “dense”, meaning every possible value occurs once.

In practice the KellarisÂ et al. results mean that database fields with small domains (like ages) could be quickly reconstructed after observing a reasonable number of queries from a legitimate user, albeit one who likes to query everything randomly.

So that’s really bad!

The main bright spot in this research —- at least up until recently — was thatÂ many types of data haveÂ much larger domains. If you’re dealing with salary data ranging from, say, $1 to $200,000, then N=200,000 and this dominant $N^4$ tends to make KellarisÂ et al. attacks impractical, simply because they’ll take too long. Similarly, data like employee last names (encoded as a form that can be sorted and range-queries) gives you even vaster domains like $N=26^{12}$ , say, and so perhaps we could pleasantly ignore these results and spend our time on more amusing engagements.

I bet we can’t ignore these results, can we?

Indeed, it seems that we can’t. The reason we can’t sit on our laurels and hope for an attacker to die of old age recovering large-domain data sets is due to something called approximate database reconstruction, or $\epsilon-$ ADR.

The setting here is the same: an attacker sits and watches an attacker make (uniformly random) range queries. The critical difference is that this attacker isn’t trying to get every database record back at its exact value: she’s willing to tolerate some degree of error, up to an additive $\epsilon N$ . For example, if I’m trying to recover employee salaries, I don’t need them to be exact: getting them within 1% or 5% is probably good enough for my purposes. Similarly, reconstructingÂ nearly all of the letters in your last name probably lets me guess the rest, especially if I know the distribution of common last names.

Which finally brings us to this new GLMPÂ paper, which puts $\epsilon-$ ADR on steroids. What it shows is that the same setting, if one is willing to “sacrifice” a few of the highest and lowest values in the database, an attacker can reconstruct nearly the full database in a much smaller (asymptotic) number of queries, specifically: $O(\epsilon^{-2} log~\epsilon^{-1})$ queries, where $\epsilon$ is the error parameter.

The important thing to notice about these results is that the valueÂ N has dropped out of the equation. The only term that’s left is theÂ error termÂ $\epsilon$ . That means these results are “scale-free”, and (asymptotically, at least), they work just as well for small values ofÂ N as large ones, and large databases and small ones. This is really remarkable.

Big-O notation doesn’t do anything for me: what does this even mean?

Big-O notation is beloved by computer scientists, but potentially meaningless in practice. There could be huge constants in these terms that render these attacks completely impractical. Besides, weird equations involving epsilon characters are impossible for humans to understand.

Sometimes the easiest way to understand a theoretical result is to plug some actual numbers in and see what happens. GLMP were kind enough to do this for us, by first generating several random databases — each containing 1,000 records, for different values ofÂ N.Â They then ran their recovery algorithm against a simulated batch of random range queries to see what the actual error rate looked like as the query count increased.

Here are their results:

GLMPgraph — Experimental results (Figure 2) from GrubbsÂ *et al.* *(GLMP,Â* 2019). The Y-axis represents the measuredÂ *error* between the reconstructed database and the actual dataset (smaller is better.) The X-axis represents the number of queries. Each database contains 1,000 records, but there are four different values ofÂ N tested here. Notice that the biggest error occurs around the very largest and smallest values in the dataset, so the results areÂ *much* better if one is willing to “sacrifice” these values.

Even after just 100 queries, the error in the dataset has been hugely reduced, and after 500 queries the contents of the database — excluding the tails — can be recovered with only about a 1-2% error rate.

Moreover, these experimental results illustrate the fact that recovery works at many scales: that is, they work nearly as well for very different values of N, ranging from 100 to 100,000. This means that the only variable you really need to think about as an attacker is:Â how close do I need my reconstruction to be? This is probably not very good news for any real data set.

How do these techniques actually work?

The answer is both very straightforward and deeply complex. The straightforward part is simple; the complex part requires an understanding of Vapnik-Chervonenkis learning theory (VC-theory) which is beyond the scope of this blog post, but is explained in the paper.

At the very highest level the recovery approach is similar to what’s been done in the past: using response probabilities to obtain record values. This paper does it much more efficiently and approximately, using some fancy learning theory results while making a few assumptions.

At the highest level: we are going to assume that the range queries are made on random endpoints ranging from 1 to N. This is a big assumption, and more on it later! Yet with just this knowledge in hand, we learn quite a bit. For example: we can compute the probability that a potential record value (say, the specific salary $34,234) is going to be sent back, provided we know the total value lies in the range 1-N (say, we know all salaries are between $1 and $200,000).

If we draw the resulting probability curve in freehand, it might look something like the chart below. This isn’t actually to scale or (probably) even accurate, but it illustrates a key point: by the nature of (random) range queries, records near the center are going to have a higher overall chance of being responsive to any given query, since the “center” values are more frequently covered by random ranges, and records near the extreme high- and low values will be chosen less frequently.

badgraph — I drew this graph freehand to mimic a picture in Kenny’s slides. Not a real plot!

The high-level goal of database reconstruction is to match the observed response rate for a given row (say, row 41) to the number of responses we’d expect see for different specific concrete values in the range. Clearly the accuracy of this approach is going to depend on the number of queries you, the attacker, can observe — more is better. And since the response rates are lower at the highest and lowest values,Â it will take more queries to guess outlying data values.

You might also notice that there is one major pitfall here. Since the graph above isÂ symmetric around its midpoint, the expected response rate will be the same for a record at .25*N and a record at .75*N — that is, a $50,000 salary will be responsive to random queries at precisely same rate as a $150,000 salary. So even if you get every database row pegged precisely to its response rate, your results might still be “flipped” horizontally around the midpoint. Usually this isn’t the end of the world, because databases aren’t normally full of unstructured random data — high salaries will be less common than low salaries in most organizations, for example, so you can probably figure out the ordering based on that assumption. But this last “bit” of information is technically not guaranteed to come back, minus some assumptions about the data set.

Thus, the recovery algorithm breaks down into two steps: first, observe the response rate for each record as random range queries arrive. For each record that responds to such a query, try to solve for a concrete value thatÂ minimizes the difference between the expected response rate on that value, and the observed rate. The probability estimation can be made more efficient (eliminating a quadratic term) by assuming that there is at least one record in the database within the range .2N-.3N (or .7N-.8N, due to symmetry). Using this “anchor” record requires a mild assumption about the database contents.

What remains is to show that the resulting attack is efficient. You can do this by simply implementing it — as illustrated by the charts above. Or you can prove that it’s efficient.Â The GLMPÂ paperÂ uses some very heavy statistical machinery to do the latter. Specifically, they make use of a result from Vapnik-Chervonenkis learning theory (VC-theory), which shows that the bound can be derived from something called the VC-dimensionÂ (which is a small number, in this case) and is unrelated to the actual value ofÂ N. That proof forms the bulk of the result, but the empirical results are also pretty good.

Is there anything else in the paper?

Yes. It gets worse. There’s so much in this paper that I cannot possibly include it all here without risking carpal tunnel and boredom, and all of it is bad news for the field of encrypted databases.

The biggest additional result is one that shows thatÂ if all you want is an approximate ordering of the database rows, then you can do this efficiently using something calledÂ a PQ tree.Â Asymptotically, this requires $O(\epsilon^{-1} log~\epsilon^{-1})$ queries, and experimentally the results are again even better than one would expect.

What’s even more important about this ordering result is that it works independently of the query distribution. That is: we do not need to have random range queries in order for this to work: it works reasonably well regardless of how the client puts its queries together (up to a point).

Even better, the authors show that this ordering, along with some knowledge of the underlying database distribution — for example, let’s say we know that it consists of U.S. citizen last names — can also be used to obtain approximate database reconstruction. Oy vey!

And there’s still even more:

The authors show how to obtain even more efficientÂ database recovery in a setting where the query range values are known to the attacker, using PAC learning. This is a more generous setting than previous work, but it could be realistic in some cases.
Finally, they extend this result toÂ prefix andÂ suffix queries, as well as range queries, and show that they can run their attacks on a dataset from the Fraternal Order of Police, obtaining record recovery in a few hundred queries.

In short: this is all really bad for the field of encrypted databases.

So what do we do about this?

I don’t know. Ignore these results? Fake our own deaths and move into a submarine?

In all seriousness: database encryption has been a controversial subject in our field. I wish I could say that there’s been an actual debate, but it’s more that different researchers have fallen into different camps, and nobody has really had the data to make their position in a compelling way. There have actually been some very personal arguments made about it.

The schools of thought are as follows:

The first holds thatÂ any kind of database encryption is better than storing records in plaintextÂ and we should stop demanding things be perfect, when the alternative is a world of constant data breaches and sadness.

To me this is a supportable position, given that the current attack model for plaintext databases is something like “copy the database files, or just run a local SELECT * query”, and the threat model for an encrypted database is “gain persistence on the server and run sophisticated statistical attacks.” Most attackers are pretty lazy, so even a weak system is probably better than nothing.

The countervailing school of thought has two points: sometimes theÂ good is much worse than the perfect, particularly if it gives application developers an outsized degree of confidence of the security that their encryption system is going to provide them.

If even the best encryption protocol is only throwing a tiny roadblock in the attacker’s way, why risk thisÂ at all? Just let the database community come up with some kind of ROT13 encryptionÂ that everyone knows to be crapÂ and stop throwing good research time into a problem that has no good solution.

I don’t really know who is right in this debate. I’m just glad to see we’re getting closer to having it.

On Ghost Users and Messaging Backdoors

The past few years have been an amazing time for the deployment of encryption. In ten years, encrypted web connections have gone from a novelty into a requirement for running a modern website.Â Smartphone manufacturers deployed defaultÂ storage encryption to billions of phones.Â End-to-end encrypted messaging and phone calls are now deployed to billions of users.

While this progress is exciting to cryptographers and privacy advocates, not everyone sees it this way. A few countries, like the U.K. and Australia, have passed laws in an attempt to gain access to this data,Â and at least one U.S. proposal has made it to Congress. The Department of Justice recently added its own branding to the mix, asking tech companies to deploy “responsible encryption“.

What, exactly, is “responsible encryption”? Well, that’s a bit of a problem. Nobody on the government’s side of the debate has really been willing to get very specific about that. In fact, a recent speech by U.S. Deputy Attorney General Rod RosensteinÂ implored cryptographers to go figure it out.

With this as background,Â aÂ recent article by GCHQ’s Ian Levy and Crispin RobinsonÂ reads like a breath of fresh air. Unlike their American colleagues, the British folks at GCHQ — essentially, the U.K.’s equivalent of NSA — seem eager to engage with the technical community and to put forward serious ideas. Indeed, Levy and Robinson make a concrete proposal in the article above: they offer a new solution designed to surveil both encrypted messaging and phone calls.

In this post I’m going to talk about that proposal as fairly as I can — given that I only have a high-level understanding of the idea. Then Iâll discuss what I think could go wrong.

A brief, illustrated primer on E2E

The GCHQ proposal deals with law-enforcement interception on messaging systems and phone calls. To give some intuition about the proposal, I first need to give a very brief (and ultra-simplified) explanation of how those systems actually work.

The basic idea in any E2E communication systems is that each participant encrypts messages (or audio/video data) directly from one device to the other. This layer of encryption reduces the need to trust your provider’s infrastructure — ranging from telephone lines to servers to undersea cables — which gives added assurance against malicious service providers and hackers.

If you’ll forgive a few silly illustrations, the intuitive result is a picture that looks something like this:

If we consider the group chat/call setting, the picture changes slightly, but only slightly. Each participant still encrypts data to the other participants directly, bypassing the provider. The actual details (specific algorithms, key choices) vary between different systems. But the concept remains the same.

The problem with the simplified pictures above is that there’s actually a lot more going on in an E2E system than just encryption.

In practice, one of the most challenging problems in encrypted messaging stems is getting the key you need to actually perform the encryption. This problem, which is generally known asÂ key distribution, is an age-old concern in the field of computer security. There are many ways for it to go wrong.

In the olden days, we used to ask users to manage and exchange their own keys, and then select which users they wanted to encrypt to. This was terrible and everyone hated it. Modern E2E systems have become popular largely because they hide all of this detail from their users. This comes at the cost of some extra provider-operated infrastructure.

In practice, systems like Apple iMessage, WhatsApp and Facebook Messenger actually look more like this:

The Apple at the top of the picture above stands in for Apple’s “identity service”, which is a cluster of servers running in Apple’s various data centers. These servers perform many tasks, but most notably: they act as a directory for looking up the encryption key of the person you’re talking to. If that service misfires and gives you the wrong key, the best ciphers in the world won’t help you. You’ll just be encrypting to the wrong person.

These identity services do more than look up keys. In at least some group messaging systems like WhatsApp and iMessage, they also control the membership of group conversations. InÂ poorly-designed systems, the server canÂ add and remove users from a group conversation at will, even if none of the participants have requested this. It’s as though you’re having a conversation in a very private room — but the door is unlocked and the building manager controls who can come enter and join you.

(A technical note: while these two aspects of the identity system serve different purposes, in practice they’re often closely related. For example, in many systems there is little distinction between “group” and “two-participant” messaging.Â For example, in systems that support multiple devices connected to a single account, like Apple’s iMessage, every single device attached to your user account is treated as a separate party to the conversation.Â Provided either party has more than one device on their account [say, an iPhone and an iPad] , you can think ofÂ every iMessage conversation as being a group conversation.)

Most E2E systems have basic countermeasures against bad behavior by the identity service.Â For example, client applications will typically alert you when a new userÂ joins your group chat, or when someone adds a new device to your iMessage account. Similarly, bothÂ WhatsApp and SignalÂ exposeÂ “safety numbers” that allow participants to verify that they received the right cryptographic keys, which offers a check against dishonest providers.

But these countermeasures are not perfect, and not every service offers them. Which brings me to the GCHQ proposal.

What GCHQ wants

TheÂ Lawfare articleÂ by Levy and Robinson does not present GCHQ’s proposal in great detail. Fortunately, both authors have spent most of the touring the U.S., giving several public talks about their ideas. I had the privilege of speaking to both of them earlier this summer when they visited Johns Hopkins, so I think I have a rough handle on what they’re thinking.

In its outlines, the idea they propose is extremely simple. The goal is to take advantage of existing the weaknesses in the identity management systems of group chat and calling systems. This would allow law enforcement — with the participation of the service provider — to add a “ghost user” (or in some cases, a “ghost device”) to an existing group chat or calling session. In systems where group membership can be modified by the provider infrastructure, this could mostly be done via changes to the server-side components of the provider’s system.

I say that it couldÂ mostly be done server-side, because there’s a wrinkle. Even if you modify the provider infrastructure to add unauthorized users to a conversation, most existing E2E systems do notify users when a new participant (or device) joins a conversation. Generally speaking, having a stranger wander into your conversation is a great way to notify criminals that the game’s afoot or what have you, so you’ll absolutely want to block this warning.

While the GCHQ proposal doesn’t go into great detail, it seems to follow that any workable proposal will require providers toÂ suppress those warning messages at the target’s device. This means the proposal will also require changes to theÂ client application as well as the server-side infrastructure.

(Certain apps like SignalÂ are already somewhat hardened against these changes, because group chat setup is handled in an end-to-end encrypted/authenticated fashion by clients. This prevents the server from inserting new users without the collaboration of at least one group participant. At the moment, however, both WhatsApp and iMessage seem vulnerable to GCHQ’s proposed approach.)

Due to this need for extensive server and client modifications, the GCHQ proposal actually represents a very significant change to the design of messaging systems. It seems likely that the client-side code changes would need to be deployed to all users, since you can’t do targeted software updates just against criminals. (Or rather, if you could rely on such targeted software updates, you would just use that capability instead of the thing that GCHQ is proposing.)

Which brings us to the last piece:Â how do get providers to go along with all of this?

While optimism and cooperation are nice in principle, it seems unlikely that communication providers are going to toÂ voluntarily insert a powerful eavesdropping capability into their encrypted services, if only because it represents a huge and risky modification. Presumably this means that the UK government will have to compel cooperation. One potential avenue for this is to useÂ Technical Capability NoticesÂ from the UK’s Investigatory Powers Act. Those notices mandate that a provider offer real-time decryption for sets of users ranging from 1-10,000 users, and moreover, that providers must design their systems to ensure this such a capability remains available.

And herein lies the problem.

Providers are already closing this loophole

The real problem with the GCHQ proposal is that it targets a weakness in messaging/calling systems that’s already well-known to providers, andÂ moreover, a weaknessÂ that providers have been working to close — perhaps because they’re worried that someone just like GCHQ (or probably, much worse) will try to exploit it. By making this proposal, the folks at GCHQ have virtually guaranteed that those providers will move much, much faster on this.

And they have quite a few options at their disposal. Over the past several years researchers have proposedÂ several designs that offerÂ transparency to users regardingÂ which keys they’re obtaining from a provider’s identity service. These systems operate by having the identity serviceÂ commit to the keys that are associated with individual users, such that it’s very hard for the provider to change a user’s keys (or to add a device) without everyone in the world noticing.

As mentioned above, advanced messengers like Signal have “submerged” the group chat management into the encrypted communications flow, so that the server cannot add new users without the digitally authenticated approval of one of the existing participants. This design, if ported to in more popular services like WhatsApp, would seem to kill the GCHQ proposal dead.

Of course, these solutions highlight the tricky nature of GCHQ’s proposal. Note that in order to take advantage of existing vulnerabilities, GCHQ is going to have to require that providers change their system. And of course, once you’ve opened the door to forcing providers to change their system, why stop with small changes? What stops the UK government from, say, taking things a step farther, and using the force of law to compel providersÂ not to harden their systems against this type of attack?

Which brings us to the real problem with the GCHQ proposal. As far as I can see, there are two likely outcomes. In the first, providers rapidly harden their system — which is good! — and in the process kill off the vulnerabilities that make GCHQ’s proposal viable (which is bad, at least for GCHQ). The more interest that governments express towards the proposal, the more likely this first outcome is. In the second outcome, the UK government, perhaps along with other governments, solve this problem byÂ forcingÂ the providers to keep their systems vulnerable. This second outcome is what I worry about.

More concretely, it’s true that today’s systems include existing flaws that are easy to exploit. But that does not mean we should entomb those flaws in concrete. And once law enforcement begins to rely on them, we will effectively have done so.Â Over time what seems like a “modest proposal” using current flaws will rapidly become an ossifying influence that holds ancient flaws in place. In the worst-case outcome, we’ll be appointing agencies likeÂ GCHQ as the ultimate architect of Apple and Facebook’s communication systems.

That is not a good outcome. In fact, it’s one that will likely slow down progress for years to come.

Let’s talk about PAKE

The first rule of PAKE is: nobody ever wants to talk about PAKE. The second rule of PAKE is that this is a shame, because PAKE â which stands for Password Authenticated Key Exchange â is actually one of the most useful technologies that (almost) never gets used. It should be deployed everywhere, and yet it isn’t.

To understand why this is such a damn shame, let’s start by describing a very real problem.

Imagine I’m operating a server that has to store user passwords. The traditional way to do this is to hash each user password and store the result in a password database. There are many schools of thought on how to handle the hashing process; the most common recommendation these days is to use a memory-hard password hashing function like scrypt or argon2 (with a unique per-password salt), and then store only the hashed result. There are various arguments about which hash function to use, and whether it could help to also use some secret value (called “pepper“), but we’ll ignore these for the moment.

Regardless of the approach you take, all of these solutions have a single achilles heel:

When the user comes back to log into your website, they will still need to send over their (cleartext) password, since this is required in order for the server to do the check.

This requirement can lead to disaster if your server is ever persistently compromised, or if your developers make a simple mistake. For example, earlier this year Twitter asked all of its (330 million!) users to change their passwords — because it turned out that company had been logging cleartext (unhashed) passwords.

Now, the login problem doesn’t negate the advantage of password hashing in any way. But it does demand a better solution: one where the user’s password never has to go to the server in cleartext. The cryptographic tool that can give this to us is PAKE, and in particular a new protocol called OPAQUE, which I’ll get to at the end of this post.

What’s a PAKE?

A PAKE protocol, first introduced by Bellovin and Merritt, is a special form of cryptographic key exchange protocol. Key exchange (or “key agreement”) protocols are designed to help two parties (call them a client and server) agree on a shared key, using public-key cryptography. The earliest key exchange protocols — like classical Diffie-Hellman — were unauthenticated, which made them vulnerable to man-in-the-middle attacks. The distinguishing feature of PAKE protocols is the client will authenticate herself to the server using a password. For obvious reasons, the password, or a hash of it, is assumed to be already known to the server, which is what allows for checking.

If this was all we required, PAKE protocols would be easy to build. What makes a PAKE truly useful is that it should also provide protection for the client’s password. A stronger version of this guarantee can be stated as follows: after a login attempt (valid, or invalid) both the client and server should learn only whether the client’s password matched the server’s expected value, and no additional information. This is a powerful guarantee. In fact, it’s not dissimilar to what we ask for from a zero knowledge proof.

pakediagram — Ideal representation of a PAKE protocol. The two parties’ inputs also include some randomness, which isn’t shown. An eavesdropper should not learn the strong shared secret key K, which should itself be *random* and not simply a function of the password.

Of course, the obvious problem with PAKE is that many people don’t want to run a “key exchange” protocol in the first place! They just want to verify that a user knows a password.

The great thing about PAKE is that the simpler “login only” use-case is easy to achieve. If I have a standard PAKE protocol that allows a client and server to agree on a shared key K if (and only if) the client knows the right password, then all we need add is a simple check that both parties have arrived at the same key. (This can be done, for example, by having the parties compute some cryptographic function with it and check the results.) So PAKE is useful even if all you’ve got in mind is password checking.

SRP: The PAKE that Time Forgot

The PAKE concept seems like it provides an obvious security benefit when compared to the naive approach we use to log into servers today. And the techniques are old, in the sense that PAKEs have been known since way back in 1992! Despite this, they’ve seen from almost no adoption. What’s going on?

There are a few obvious reasons for this. The most obvious has to do with the limitations of the web: it’s much easier to put a password form onto a web page than it is to do fancy crypto in the browser. But this explanation isn’t sufficient. Even native applications rarely implement PAKE for their logins. Another potential explanation has to do with patents, though most of these are expired now. To me there are two likely reasons for the ongoing absence of PAKE: (1) there’s a lack of good PAKE implementations in useful languages, which makes it a hassle to use, and (2) cryptographers are bad at communicating the value of their work, so most people don’t know PAKE is even an option.

Even though I said PAKE isn’t deployed, there are some exceptions to the rule.

One of the remarkable ones is a 1998 protocol designed by Tom Wu [correction: not Tim Wu] and called “SRP”. Short for “Secure Remote Password“, this is a simple three-round PAKE with a few elegant features that were not found in the earliest works. Moreover, SRP has the distinction of being (as far as I know) the most widely-deployed PAKE protocol in the world. I cite two pieces of evidence for this claim:

SRP has been standardized as a TLS ciphersuite, and is actually implemented in libraries like OpenSSL, even though nobody seems to use it much.
Apple uses SRP extensively in their iCloud Key Vault.

This second fact by itself could make SRP one of the most widely used cryptographic protocols in the world, so vast is the number of devices that Apple ships. So this is nothing to sneer at.

Industry adoption of SRP is nice, but also kind of a bummer: mainly because while any PAKE adoption is cool, SRP itself isn’t the best PAKE we can deploy. I was planning to go into the weeds about why I feel so strongly about SRP, but it got longwinded and it distracted from the really nice protocol I actually want to talk about further below. If you’re still interested, I moved the discussion onto this page.

In lieu of those details, let me give a quick and dirty TL;DR on SRP:

SRP does some stuff “right”. For one thing, unlike early PAKEs it does not require you to store a raw password on the server (or, equivalently, a hash that could be used by a malicious client in place of the password). Instead, the server stores a “verifier” which is a one-way function of the password hash. This means a leak of the password database does not (immediately) allow the attacker to impersonate the user — unless they conduct further expensive dictionary attacks. (The technical name for this is “asymmetric” PAKE.)
Even better, the current version of SRP (v4 v6a) isn’t obviously broken!
However (and with no offense to the designers) the SRP protocol design is completely bonkers, and earlier versions have been broken several times — which is why we’re now at revision 6a. Plus the “security proof” in the original research paper doesn’t really prove anything meaningful.
SRP currently relies on integer (finite field) arithmetic, and for various reasons (see point 3 above) the construction is not obviously transferable to the elliptic curve setting. This requires more bandwidth and computation, and thus SRP can’t take advantage of the many efficiency improvements we’ve developed in settings like Curve25519.
SRP is vulnerable to pre-computation attacks, due to the fact that it hands over the user’s “salt” to any attacker who can start an SRP session. This means I can ask a server for your salt, and build a dictionary of potential password hashes even before the server is compromised.
Despite all these drawbacks, SRP is simple — and actually ships with working code. Plus there’s working code in OpenSSL that even integrates with TLS, which makes it relatively easy to adopt.

Out of all these points, the final one is almost certainly responsible for the (relatively) high degree of commercial success that SRP has seen when compared to other PAKE protocols. It’s not ideal, but it’s real. This is something for cryptographers to keep in mind.

OPAQUE: The PAKE of a new generation

When I started thinking about PAKEs a few months ago, I couldn’t help but notice that most of the existing work was kind of crummy. It either had weird problems like SRP, or it required the user to store the password (or an effective password) on the server, or it revealed the salt to an attacker — allowing pre-computation attacks.

Then earlier this year, Jarecki, Krawczyk and Xu proposed a new protocol called OPAQUE. Opaque has a number of extremely nice advantages:

It can be implemented in any setting where Diffie-Hellman and discrete log (type) problems are hard. This means that, unlike SRP, it can be easily instantiated using efficient elliptic curves.
Even better: OPAQUE does not reveal the salt to the attacker. It solves this problem by using an efficient “oblivious PRF” to combine the salt with the password, in a way that ensures the client does not learn the salt and the server does not learn the password.
OPAQUE works with any password hashing function. Even better, since all the hashing work is done on the client, OPAQUE can actually take load off the server, freeing an online service up to use much strong security settings — for example, configuring scrypt with large RAM parameters.
In terms of number of messages and exponentiations, OPAQUE is not much different from SRP. But since it can be implemented in more efficient settings, it’s likely to be a lot more efficient.
Unlike SRP, OPAQUE has a reasonable security proof (in a very strong model).

There’s even an Internet Draft proposal for OPAQUE, which you can read here. Unfortunately, at this point I’m not aware of any production quality implementations of the code (if you know of one, please link to it in the comments and I’ll update). (Update: There are several potential implementations listed in the comments — I haven’t looked closely enough to endorse any, but this is great!) But that should soon change.

The full OPAQUE protocol is given a little bit further below. In the rest of this section I’m going to go into the weeds on how OPAQUE works.

Problem 1: Keeping the salt secret. As I mentioned above, the main problem with earlier PAKEs is the need to transmit the salt from a server to a (so far unauthenticated) client. This enables an attacker to run pre-computation attacks, where they can build an offline dictionary based on this salt.

The challenge here is that the salt is typically fed into a hash function (like scrypt) along with the password. Intuitively someone has to compute that function. If it’s the server, then the server needs to see the password — which defeats the whole purpose. If it’s the client, then the client needs the salt.

In theory one could get around this problem by computing the password hashing function using secure two-party computation (2PC). In practice, solutions like this are almost certainly not going to be efficient — most notably because password hashing functions are designed to be complex and time consuming, which will basically explode the complexity of any 2PC system.

OPAQUE gets around this with the following clever trick. They leave the password hash on the client’s side, but they don’t feed it the stored salt. Instead, they use a special two-party protocol called an oblivious PRF to calculate a second salt (call it salt2) so that the client can use salt2 in the hash function — but does not learn the original salt.

It works like this:

The server stores "salt", and the client has the password.â©â©salt2 = PRF(salt, password) // This is calculated between the â©                            // client and server, using an obliviousâ©                            // protocol where the client never learnsâ©                            // salt, and the server never learnsâ©                            // the password. The client obtains salt2â©â©K      = PasswordHash(salt2, password) // This is done on the client

The actual implementation of the oblivious PRF can be done using a couple of group elements and exponentiations. Even better, if the client enters the wrong password into that protocol, she obtains a completely bogus “salt2” value that reveals nothing about the real salt value.

Problem 2: Proving that the client got the right key K. Of course, at this point, the client has derived a key K, but the server has no idea what it is. Nor does the server know whether it’s the right key.

The solution OPAQUE uses based an old idea due to Gentry, Mackenzie and Ramzan. When the user first registers with the server, she generates a strong public and private key for a secure agreement protocol (like HMQV), and encrypts the resulting private key under K, along with the server’s public key. The resulting authenticated ciphertext (and the public key) is stored in the password database.

C = Encrypt(K, client secret key | server’s public key)

When the client wishes to authenticate using the OPAQUE protocol, the server sends it the stored ciphertext C. If the client entered the right password into the first phase, she can derive K, and now decrypt this ciphertext. Otherwise it’s useless. Using the embedded secret key, she can now run a standard authenticated key agreement protocol to complete the handshake. (The server verifies the clients’ inputs against its copy of the client’s public key, and the client does similarly.)

Putting it all together. All of these different steps can be merged together into a single protocol that has the same number of rounds as SRP. Leaving aside the key verification steps, it looks like the protocol above. Basically, just two messages: one from the client and one returned to the server.

The final aspect of the OPAQUE work is that it includes a strong security proof that shows the resulting protocol can be proven secure under the 1-more discrete logarithm assumption in the random oracle model, which is a (well, relatively) standard assumption that appears to hold in the settings we work with.

In conclusion

So in summary, we have this neat technology that could make the process of using passwords much easier, and could allow us to do it in a much more efficient way — with larger hashing parameters, and more work done by the client? Why isn’t this everywhere?

Maybe in the next few years it will be.

Why I’m done with Chrome

This blog is mainly reserved for cryptography, and I try to avoid filling it with random “someone is wrong on the Internet” posts. After all, that’s what Twitter is for! But from time to time something bothers me enough that I have to make an exception. Today I wanted to write specifically about Google Chrome, how much I’ve loved it in the past, and why — due to Chrome’s new user-unfriendly forced login policy — I won’t be using it going forward.

A brief history of Chrome

When Google launched Chrome ten years ago, it seemed like one of those rare cases where everyone wins. In 2008, the browser market was dominated by Microsoft, a company with an ugly history of using browser dominance to crush their competitors. Worse, Microsoft was making noises about getting into the search business. This posed an existential threat to Google’s internet properties.

In this setting, Chrome was a beautiful solution. Even if the browser never produced a scrap of revenue for Google, it served its purpose just by keeping the Internet open to Google’s other products. As a benefit, the Internet community would receive a terrific open source browser with the best development team money could buy. This might be kind of sad for Mozilla (who have paid a high price due to Chrome) but overall it would be a good thing for Internet standards.

For many years this is exactly how things played out. Sure, Google offered an optional “sign in” feature for Chrome, which presumably vacuumed up your browsing data and shipped it off to Google, but that was an option. An option you could easily ignore. If you didn’t take advantage of this option, Google’s privacy policy was clear: your data would stay on your computer where it belonged.

What changed?

A few weeks ago Google shipped an update to Chrome that fundamentally changes the sign-in experience. From now on, every time you log into a Google property (for example, Gmail), Chrome will automatically sign the browser into your Google account for you. It’ll do this without asking, or even explicitly notifying you. (However, and this is important: Google developers claim this will not actually start synchronizing your data to Google — yet. See further below.)

Your sole warning — in the event that you’re looking for it — is that your Google profile picture will appear in the upper-right hand corner of the browser window. I noticed mine the other day:

foo

The change hasn’t gone entirely unnoticed: it received some vigorous discussion on sites like Hacker News. But the mainstream tech press seems to have ignored it completely. This is unfortunate — and I hope it changes — because this update has huge implications for Google and the future of Chrome.

In the rest of this post, I’m going to talk about why this matters. From my perspective, this comes down to basically four points:

Nobody on the Chrome development team can provide a clear rationale for why this change was necessary, and the explanations they’ve given don’t make any sense.
This change has enormous implications for user privacy and trust, and Google seems unable to grapple with this.
The change makes a hash out of Google’s own privacy policies for Chrome.
Google needs to stop treating customer trust like it’s a renewable resource, because they’re screwing up badly.

I warn you that this will get a bit ranty. Please read on anyway.

Google’s stated rationale makes no sense

The new feature that triggers this auto-login behavior is called “Identity consistency between browser and cookie jar” (HN). After conversations with two separate Chrome developers on Twitter (who will remain nameless — mostly because I don’t want them to hate me), I was given the following rationale for the change:

To paraphrase this explanation: if you’re in a situation where you’ve already signed into Chrome and your friend shares your computer, then you can wind up accidentally having your friend’s Google cookies get uploaded into your account. This seems bad, and sure, we want to avoid that.

But note something critical about this scenario. In order for this problem to apply to you, you already have to be signed into Chrome. There is absolutely nothing in this problem description that seems to affect users who chose not to sign into the browser in the first place.

So if signed-in users are your problem, why would you make a change that forces unsigned–in users to become signed-in? I could waste a lot more ink wondering about the mismatch between the stated “problem” and the “fix”, but I won’t bother: because nobody on the public-facing side of the Chrome team has been able to offer an explanation that squares this circle.

And this matters, because “sync” or not…

The change has serious implications for privacy and trust

The Chrome team has offered a single defense of the change. They point out that just because your browser is “signed in” does not mean it’s uploading your data to Google’s servers. Specifically:

While Chrome will now log into your Google account without your consent (following a Gmail login), Chrome will not activate the “sync” feature that sends your data to Google. That requires an additional consent step. So in theory your data should remain local.

This is my paraphrase. But I think it’s fair to characterize the general stance of the Chrome developers I spoke with as: without this “sync” feature, there’s nothing wrong with the change they’ve made, and everything is just fine.

This is nuts, for several reasons.

User consent matters. For ten years I’ve been asked a single question by the Chrome browser: “Do you want to log in with your Google account?” And for ten years I’ve said no thanks. Chrome still asks me that question — it’s just that now it doesn’t honor my decision.

The Chrome developers want me to believe that this is fine, since (phew!) I’m still protected by one additional consent guardrail. The problem here is obvious:

If you didn’t respect my lack of consent on the biggest user-facing privacy option in Chrome (andÂ didn’t even notify me that you had stopped respecting it!) why should I trust any other consent option you give me? What stops you from changing your mind on that option in a few months, when we’ve all stopped paying attention?

The fact of the matter is that I’d never even heard of Chrome’s “sync” option — for the simple reason that up until September 2018, I had never logged into Chrome. Now I’m forced to learn these new terms, and hope that the Chrome team keeps promises to keep all of my data local as the barriers between “signed in” and “not signed in” are gradually eroded away.

The Chrome sync UI is a dark pattern. Now that I’m forced to log into Chrome, I’m faced with a brand new menu I’ve never seen before. It looks like this:

Thing

Does that big blue button indicate that I’mÂ already synchronizing my data to Google? That’s scary! Wait, maybe it’s an invitation to synchronize! If so, what happens to my data if I click it by accident? (I won’t give it the answer away, you should go find out. Just make sure you don’t accidentally upload all your data in the process. It can happen quickly.)

In short, Google has transformed the question of consenting to data upload from something affirmative that I actually had to put effort into — entering my Google credentials and signing into Chrome — into something I can now do with a single accidental click. This is a dark pattern. Whether intentional or not, it has the effect of making it easy for people to activate sync without knowing it, or to think they’re already syncing and thus there’s no additional cost to increasing Google’s access to their data.

Don’t take my word for it. It even gives (former) Google people the creeps.

Big brother doesn’t need to actually watch you. We tell things to our web browsers that we wouldn’t tell our best friends. We do this with some vague understanding that yes, the Internet spies on us. But we also believe that this spying is weak and probabilistic. It’s not like someone’s standing over our shoulder checking our driver’s license with each click.

What happens if you take that belief away? There are numerous studies indicating that even theÂ perception of surveillance can significantly greatly magnify the degree of self-censorship users force on themselves. Will user feel comfortable browsing for information on sensitive mental health conditions — if their real name and picture are always loaded into the corner of their browser? The Chrome development team says “yes”. I think they’re wrong.

For all we know, the new approach has privacy implications even if sync is off.Â The Chrome developers claim that with “sync” off, a Chrome has no privacy implications. This might be true. But when pressed on the actual details, nobody seems quite sure.

For example, if I have my browser logged out, then I log in and turn on “sync”, does all my past (logged-out) data get pushed to Google? What happens if I’m forced to be logged in, and then subsequently turn on “sync”? Nobody can quite tell me if the data uploaded in these conditions is the same. These differences could really matter.

The changes make hash of the Chrome privacy policy

The Chrome privacy policy is a remarkably simple document. Unlike most privacy policies, it was clearly written as a promise to Chrome’s users — rather than as the usual lawyer CYA. Functionally, it describes two browsing modes: “Basic browser mode” and “signed-in mode”. These modes have very different properties. Read for yourself:

Untitled 2 Untitled 3

In “basic browser mode”, your data is stored locally. In “signed-in” mode, your data gets shipped to Google’s servers. This is easy to understand. If you want privacy, don’t sign in. But what happens if your browser decides to switch you from one mode to the other, all on its own?

Technically, the privacy policy is still accurate. If you’re in basic browsing mode, your data is still stored locally. The problem is that you no longer get to decide which mode you’re in. This makes a mockery out of whatever intentions the original drafters had. Maybe Google will update the document to reflect the new “sync” distinction that the Chrome developers have shared with me. We’ll see.

Update: After I tweeted about my concerns, I received a DM on Sunday from two different Chrome developers, each telling me the good news: Google is updating their privacy policy to reflect the new operation of Chrome. I think that’s, um, good news. But I also can’t help but note that updating a privacy policy on a weekend is an awful lot of trouble to go to for a change that… apparently doesn’t even solve a problem for signed-out users.

Trust is not a renewable resource

For a company that sustains itself by collecting massive amounts of user data, Google hasÂ managed to avoid the negative privacy connotations we associate with, say, Facebook. This isn’t because Google collects less data, it’s just that Google has consistently been more circumspect and responsible with it.

Where Facebook will routinely change privacy settings and apologize later, Google has upheld clear privacy policies that it doesn’t routinely change. Sure, when it collects, it collects gobs of data, but in the cases where Google explicitly makes user security and privacy promises — it tends to keep them. This seems to be changing.

Google’s reputation is hard-earned, and it can be easily lost. Changes like this burn a lot of trust with users. If the change is solving an absolutely critical problem for users , then maybe a loss of trust is worth it. I wish Google could convince me that was the case.

Conclusion

This post has gone on more than long enough, but before I finish I want to address two common counterarguments I’ve heard from people I generally respect in this area.

One argument is that Google already spies on you via cookies and its pervasive advertising network and partnerships, so what’s the big deal if they force your browser into a logged-in state? One individual I respect described the Chrome change as “making you wear two name tags instead of one”. I think this objection is silly both on moral grounds — just because you’re violating my privacy doesn’t make it ok to add a massive new violation — but also because it’s objectively silly. Google has spent millions of dollars adding additional tracking features to both Chrome and Android. They aren’t doing this for fun; they’re doing this because it clearly produces data they want.

The other counterargument (if you want to call it that) goes like this: I’m a n00b for using Google products at all, and of course they were always going to do this. The extreme version holds that I ought to be using lynx+Tor and DJB’s custom search engine, and if I’m not I pretty much deserve what’s coming to me.

I reject this argument. I think It’s entirely possible for a company like Google to make good, usable open source software that doesn’t massively violate user privacy. For ten years I believe Google Chrome did just this.

Why they’ve decided to change, I don’t know. It makes me sad.

Friday Dachshund Blogging

For over a year this blog has failed to deliver on an essential promise — that there would someday be pictures of dachshunds. Today we deliver.

This is Callie (short for Calliope) working her way through a bit of summer crypto reading:

But sometimes that’s exhausting and you’ve gotta take a break.

A visit from a strange metallic dachshund:

Summer:

And in memoriam, Zoe and Sophie, who helped me start this blog.

Wonk post: chosen ciphertext security in public-key encryption (Part 2)

This continues the post from Part 1. Note that this is a work in progress, and may have some bugs in it ð I’ll try to patch them up as I go along.

In the previous post I discussed the problem of building CCA-secure public key encryption. Here’s a quick summary of what we discussed in the first part:

We covered the definition of CCA2 security.
We described how you can easily achieve this notion in theÂ symmetric encryption setting using a CPA-secure encryption scheme, plus a secure MAC.
We talked about why this same approach doesn’t work for standard public-key encryption.

In this post I’m going to discuss a few different techniques that actuallyÂ do provide CCA security for public key encryption. We’ll be covering these in no particular order.

A quick note on security proofs. There are obviously a lot of different ways you couldÂ try to hack together a CCA2 secure scheme out of different components. Some of those might be secure, or they might not be. In general, the key difference between a “secure” and “maybe secure” scheme is the fact that we can construct some kind of security proof for it.

The phrase “some kind” will turn out to be an important caveat, because these proofs might require a modest amount of cheating.

The bad and the ugly

Before we get to the constructive details, it’s worth talking a bit about some ideas thatÂ don’tÂ work to achieve CCA security. The most obvious place to start is with some of the early RSA padding schemes, particularly theÂ PKCS#1v1.5Â padding standard.

PKCS#1 padding was developed in the 1980s, when it was obvious that public key encryption was going to become widely deployed. It was intended as a pre-processing stage for messages that were going to be encrypted using an RSA public key.

This padding scheme had two features. First, it addedÂ randomness to the message prior to encrypting it. This was designed to defeat the simple ciphertext guessing attacks that come from deterministic encryption schemes like RSA. It can be easily shown that randomized encryption is absolutelyÂ necessary for any IND-CPA (and implicitly, IND-CCA) secure public key encryption scheme. Second, the padding added some “check” bytes that were intended to help detect mangled ciphertexts after decryption; this was designed (presumably) to shore the scheme up against invalid decryption attempts.

PKCS#1v1.5 is still widely used in protocols, includingÂ all versions ofÂ TLS prior to TLS 1.3. The diagram below shows what the padding scheme looks like when used in TLS with a 2048-bit RSA key. The section labeled “48 bytes PMS” (pre-master secret) in this example represents the plaintext being encrypted. The 205 “non-zero padding” consists of purely random bytes that exclude the byte “0”, because that value is reserved to indicate the end of the padding section and the beginning of the plaintext.

After using the RSA secret key to recover the padded message, the decryptor is supposed to parse the message and verify that the first two bytes (“00 02”) and the boundary “00” byte are all correct and in not violating any rules. The decryptor may optionally conduct other checks like verifying the length and structure of the plaintext, in case that’s known in advance.

One of the most immediate observations about PKCS#1v1.5 is that the designersÂ kind of intuitively understood that chosen ciphertext attacks were a thing. They clearly added some small checks to make sure that it would be hard for an attacker to modify a given ciphertext (e.g., by multiplying it by a chosen value). It’s also obvious that these checks aren’t very strong. In the standardized version of the padding scheme, there are essentially three bytes to check — and one of them (the “00” byte after the padding) can “float” at a large number of different positions, depending on how much padding and plaintext there is in the message.

The use of a weak integrity check leads to a powerful CCA2 attack on the encryption scheme that was first discovered by Daniel Bleichenbacher. The attack is powerful due to the fact that it actuallyÂ leverages the padding check as a way to learn information about the plaintext. That is: the attacker “mauls” a ciphertext and sends it to be decrypted, and relies on the fact that the decryptorÂ willÂ simply perform the decryption checks they’re supposed to perform — and output a noticable error if they fail. Given only this one bit of information per decryption, the attack can gradually recover the full plaintext of a specific ciphertext by (a) multiplying it with some value, (b) sending the result to be decrypted, (c) recording the success/failure result, (d) adaptively picking a new value and repeating step (a) many thousands or millions of times.

The PKCS#1v1.5 padding scheme is mainly valuable to us today because it provides an excellent warning to cryptographic engineers, who would otherwise continue to follow the “you can just hack together something that looks safe” school of building protocols. Bleichenbacher-style attacks have largely scared the crypto community straight. Rather than continuing to use this approach,Â the crypto community has (mostly) moved towards techniques that at least offer some semblance ofÂ provable security.

That’s what we’ll cover in just a moment.

A few quick notes on achieving CCA2-secure public key encryption

Before we get to a laundry list of specific techniques and schemes, it’s worth askingÂ what types of design features we might be looking for in a CCA2 public key encryption scheme. Historically there have been two common requirements:

It would be super convenient if we could start with an existing encryption scheme, like RSA or Elgamal encryption, and generically tweak (or “compile”) that scheme into a CCA2-secure scheme. (Re-usable generic techniques areÂ particularly useful in the event that someone comes up with new underlying encryption schemes, like post-quantumÂ secure ones.)
The resulting scheme should be pretty efficient. That rules out most of the earlyÂ theoretical techniquesÂ that use huge zero knowledge proofs (as cool as they are).

Before we get to the details, I also want to repeat the intuitive description of the CCA2 security game, which I gave in the previous post.Â The game (or “experiment”) works like this:

I generate an encryption keypair for a public-key scheme and give you the public key.
You can send me (sequentially and adaptively) many ciphertexts, which I will decrypt with my secret key. Iâll give you the result of each decryption.
Eventually youâll send me a pair of messages (of equal length)Â $M_0, M_1$ Â and Iâll pick a bitÂ $b$ Â at random, and return to you the encryption ofÂ $M_b$ , which I will denote asÂ $C^* \leftarrow {\sf Encrypt}(pk, M_b)$ .
Youâll repeat step (2), sending me ciphertexts to decrypt. If you send meÂ $C^*$ Â Iâll reject your attempt. But Iâll decrypt any other ciphertext you send me, even if itâs only slightly different fromÂ $C^*$ .
You (the attacker) will output your guessÂ $b'$ . They âwinâ the game ifÂ $b'=b$ .
We say a scheme is IND-CCA2 secure if the attacker wins with probability “not much greater” than 1/2 (which is the best an attacker can do if they just guess randomly.)

A quick review of this definition shows that we need a CCA2-encryption scheme to provide at least two major features.

First off, it should be obvious that the scheme must not leak information about the secret key,Â even when I’m using it to decrypt arbitrary chosen ciphertexts of your choice.Â There are obvious examples of schemes that fail to meet this requirement: the most famous is the (textbook) Rabin cryptosystem — where the attacker’s ability to obtain the decryption of a single chosen ciphertext can leak the entire secret key.

More subtly, it seems obvious that CCA2 security is related toÂ non-malleability.Â Here’s why: suppose I receive a challenge ciphertext $C^*$ at step (3). It must be the case that I cannot easily “maul” that ciphertext into a new ciphertext $C'$ that contains a closely related plaintext (and that the challenger will be able and willing to meaingfully decrypt). It’s easy to see thatÂ if I could get away with this, by the rules of the game I could probably win at step (4), simply by sending $C'$ in to be decrypted, getting the result, and seeing whether it’s more closely related to $M_0$ or $M_1$ . (This is, in fact, a very weak explanation of what the Bleichenbacher attack does.)

It turns out that an even stronger property that helps achieve both of these conditions is something calledÂ plaintext awareness. There are various subtly-different mathematical formulations of this idea, but here I’ll try to give only the English-language intuition:

If the attacker is able to submit a (valid) ciphertext to be decrypted, it must be the case that she already knows the plaintext of that message.

This guarantee is very powerful, because it helps us to be sure that the decryption process doesn’t give the attacker anyÂ new information that she doesn’t already have. She can submit any messages she wants (including mauling the challenge ciphertext $C^*$ ) but if this plaintext-awareness property holds in the strongest sense, those decryptions won’t tell her anything she doesn’t already know.

Of course, just because your scheme appears to satisfy the above conditions does not mean it’s secure.Â Both rules above are heuristics: that is, they’re necessary conditions to prevent attacks, but they may or may not be sufficient. To really trust a scheme (in the cryptographic sense) we should be able to offer aÂ proof (under some assumptions) that these guarantees hold. We’ll address that a bit as we go forward.

Technique 1: Optimal Asymmetric Encryption Padding

One of the earlierÂ practical CCA2 transforms was developed by Bellare and Rogaway as a direct replacement for the PKCS#1v1.5 padding scheme in RSA encryption. The scheme they developed — called Optimal Asymmetric Encryption Padding — represents a “drop-in” replacement for the earlier, broken v1.5 padding scheme. It also features a security proof. (Mostly. We’ll come back to this last point.)

(Confusingly, OAEP was adopted into the PKCS#1 standards as of version 2.0, so sometimes you’ll see it referred to as PKCS#1v2.0-OAEP.)

OAEP’s most obvious advance over the previous state of the art is the addition of not one, butÂ two separate hash functions $G()$ and $H()$ that don’t exist in the v1.5 predecessor. (These are sometimes referred to as “mask generation functions”, which is just a fancy way of saying they’re hash functions with outputs of a custom, chosen size. Such functions can be easily built from existing hash functions like SHA256.)

Expressed graphically, this is what OAEP it looks like:

OAEP padding function (courtesy Ozga at Wikipedia). The message isÂ m andÂ rÂ is a string of random bits. The “000” represents a “check string” consisting of a string ofÂ k1 “0” bits. The lengthsÂ *k0, k1* are chosen by the scheme, and the length of the overall input should be the largest bit (or byte) string that can fit inside of an RSA modulus (e.g., 1024 bits). Some 0 bits/bytes may have to be pre-pended to the result if the padded result smaller than the modulus.Â

If you’ve ever seen the DES cipher, this structure should look familiar to you. Basically OAEP is a two-round (unkeyed) Feistel network that uses a pair of hash functions to implement the round functions. There are a few key observations you can make right off the bat:

Just looking at the diagram above, you can see that it’s very easy to compute this padding function forward (going from a plaintext $m$ and some random padding $r$ to a padded message) and backwards — that is, it’s an easily-invertible permutation. The key to this feature is the Feistel network structure.
Upon decryption, a decryptor can invert the padding of a given message and verify that the “check string” (the string ofÂ k1Â “0” bits) is correctly structured. If this string is not structured properly, the decryptor can simply output an error. This comprises the primary decryption check.
Assuming some (strong) properties of the hash functions, it intuitively seems that the OAEP transform is designed to create a kind of “avalanche effect” where even a small modification of a padded message will result in aÂ very different unpadded result when the transform is inverted. In practice any such modification should “trash” the check string with overwhelming probability.

From an intuitive point of view, these last two properties are what makes OAEP secure against chosen-ciphertext attacks. The idea here is that, due to the random properties of the hash function, it should be hard for the attacker to construct a valid ciphertext (one that has a correct check string) if she does not already know the plaintext that goes into the transform. This should hold even if the attacker already has some known valid ciphertext (like $C^*$ ) that she wishes to maul.

More specifically related to mauling: if I send an RSA-OAEP ciphertext $C^*$ that encrypts a specific message $m$ , the attacker should not be able to easilyÂ maul that ciphertext into a different ciphertext $C'$ that will still pass the decryption checks. This is due to two facts: (1) because RSA is a (trapdoor) permutation, any change to $C^*$ will implicitly change the padded message your recover after inverting the RSA function. And (2) sending this altered padded message backwards through the OAEP transform should, with overwhelming probability, trash the check string (and the message $m$ ). The result is that the adversaryÂ can’tÂ maul someone else’s ciphertext.

This all assumes someÂ very strong assumptions about the hash functions, which we’ll discuss below.

The OAEP proof details (at the most ridiculously superficial level)

Proving OAEP secure requires two basic techniques. Both fundamentally rely on the notion that the functions $G()$ and $H()$ areÂ random oracles.Â This is important for two very different reasons.

First: assuming a function is a “random oracle” means that we’re assuming it to have the same behavior as aÂ random function. This is an awesome property for a hash function to have! (Note: real hash functionsÂ don’t have it. This means that hypothetically they could have very ‘non-random’ behavior that would make RSA-OAEP insecure. In practice this has not yet been a practical concern for real OAEP implementations, but it’s worth keeping in mind.

It’s easy to see that if the hash functions $G()$ and $H()$ wereÂ random functions, it would give OAEP some very powerful properties. Remember, one of the main intuitive goals of the OAEP scheme is to prevent attackers from successfully getting you to decrypt an improperly-constructed (e.g., mauled) ciphertext.Â If both hash functions are truly random, then this implies that any invalid ciphertext will almost certainly fail decryption, because the padding check will fail.

At a much deeper level, the use of random oracles in RSA’s security proof gives the security reduction a great deal of “extra power” to handle things like decrypt chosen ciphertexts. This is due to the fact that, in a random oracle proof, the proof reduction is allowed to both “see” every value hashed through those hash functions, and also to “program” the functions so that they will produce specific outputs. This would not be possible if $G()$ and $H()$ were implemented using real hash functions, and so the entire security proof would break down.

These properties provide a tool in the security proof to enable decryption even when the secret key is unknown. In a traditional proof of the RSA-OAEP scheme, the idea is to show that an attacker who breaks the encryption (in the IND-CCA2 sense) can be used to construct a second attacker who solves the RSA problem. This is done by taking some random values $(N, e, C)$ where $N, e$ is an RSA public key of unknown factorization and “programming” the random oracles such that $C^* = C$ . The intuitive idea is that an attacker who is able to learn something about the underlying message must query the functions $G()$ and $H()$ on correct inputs that, ultimately will allow the security reduction to obtain the RSA inverse of $C^*$ even when the reduction does not know the RSA secret key, That is, such an attacker will allow us to find an integer $M'$ such that $M'^e = C$ .

(There turned out to be some issues in the original OAEP proof that make it not quite work forÂ arbitrary trapdoor permutations. Shoup fixed these by providing a new padding padding scheme called OAEP+, but the original OAEP had since gone into heavy usage within standards! It turns out that RSA-OAEP does work, however, for RSA with public exponents 3 and other exponents, though proving this required some ugly band-aids. This whole story is part of a cautionary tail about provably security, which Koblitz discusses here.)

Technique 2: The Fujisaki-Okamoto Transform

One limitation of OAEP (and OAEP+) padding is that it requires a trapdoor permutation in order to work. This applies nicely to RSA encryption, but does not necessarily work with every existing public-key encryption scheme. This motivates the need for other CCA transforms that work with arbitrary existing (non-CCA) encryption schemes.

One of the nicest generic techniques for building CCA2-secure public-key encryption is due toÂ Eiichiro Fujisaki and Tatsuaki Okamoto. The idea of this transform is to begin with a scheme that already meets the definition of IND-CPA security — that is, it is semantically secure, but not against chosen ciphertext attacks. (For this description, we’ll also require that this scheme has a large [exponentially-sized] message space and some specific properties related to randomness.) The beauty of the “Fujisaki-Okamoto transform” (henceforth: F-O) is that, like OAEP before it, given a working public-key encryption scheme, it requires only the addition of some hash functions, and can be proven secure in the random oracle model.

Let’s imagine that we have an IND-CPA encryption public-key encryption algorithm that consists of the algorithms ${\sf KeyGen}, {\sf Encrypt}, {\sf Decrypt}$ . We’ll also make use of two independent hash functions $H_1, H_2$ .

A key observation here is that in every IND-CPA (semantically secure) public key encryption scheme, the ${\sf Encrypt}$ algorithm is randomized. This actuallyÂ has to be the case, due to the definition of IND-CPA. (See here for a discussion of why that is.) Put more explicitly, what this means is that the encryption algorithm must have acccess to some set of random bits that will be used to produce the ciphertext.

The main trick that the F-O transform uses is toÂ de-randomizeÂ this public-key encryption algorithm. Instead of using real random bits to encrypt, it will instead use the output of the hash function $H_1$ to produce the random bits that will be used for encryption. This turns a randomized encryption into a deterministic one. (This, of course, requires that both the input and the internals of $H_1$ are capable of producing bits that “look” random.)

Let’s get to the nuts and bolts. The F-O transform does not change the key generation algorithm of the original encryption scheme at all, except to specify the hash functions $H_1, H_2$ . The main changes come in the new encryption and decryption algorithms. I’m going to present one variant of the transform, though there are others. This one works as follows.

To encrypt a message $M$ , which we’ll express as some fixed-length string of bits:

Instead of encrypting the actual message $M$ , we instead sample a random message $R$ from the message space of the original CPA-secure scheme.
We hash the random message $R$ together with the original message $M$ using that first hash function $H_1$. The output of this function will give us a ‘random’ bitstring. Let’s denote this as: $r \leftarrow H_1(R \| M)$ .
Next, we’ll encrypt the new random message $R$ using the original (CPA-secure) encryption scheme’s ${\sf Encrypt}$ algorithm, but critically:Â we will use the bits $r$ as the randomness for that encryption. The result of this process will give the first part of the ciphertext: $C_1 \leftarrow {\sf Encrypt}(pk, R; r)$ . Note that here $r$ just refers to the randomness for the encryption algorithm, not an actual message being encrypted.
Finally, we derive a “key” for encrypting the real message we want to send. We can compute this as $K \leftarrow H_2(R)$ .
We now encrypt the original message $M$ we want to send using some secure encryption scheme, for example the simple one-time pad: $C_2 \leftarrow M \oplus K$ .
We output the “ciphertext” $C = (C_1, C_2)$ .

To decrypt $C = (C_1, C_2)$ , we would perform the following steps:

First, use the original public-key encryption scheme’s secret key to decrypt the ciphertext $C_1$ , which (if all is well) should give us $R' \leftarrow {\sf Decrypt}(sk, C_1)$ .
Now use knowledge of $R'$ to recover the key $K' \leftarrow H_2(R')$ and thus the message $M'$ which we can obtain as $M' \leftarrow C_2 \oplus K'$ .
Now check that both $R', M'$ are valid byÂ re-computing the randomness $r' \leftarrow H_1(R' \| M')$ and verifying the condition $C_1 == {\sf Encrypt}(pk, R'; r')$ . If this final check fails, simply output a decryption error.

Phew. So what the heck is going on here?

Let’s tackle this scheme from a practical perspective. Earlier in this post, we said that to achieve IND-CCA2 security, a scheme must have two features. First, it must beÂ plaintext aware, which means that in order to construct a valid ciphertext (that passes all decryption checks) the attacker should already know the plaintext.

Does F-O have this property? Well, intuitively we wouldÂ hope that the answer is “yes”. Note for some valid F-O ciphertext $C = (C_1, C_2)$ the decrypted plaintext is implicitly defined as $M' \leftarrow C_2 \oplus H_2(R')$ . So what we really want to prove is thatÂ in order to construct a valid ciphertext the attacker must already know $R'$ and $M'$ prior to sending the message for decryption.

This guarantee (with high probability) comes from the structure of $C_1$ . In order for the ciphertext to be considered valid by the decryptor, it must be the case that $C_1$ satisfies the check $C_1 == {\sf Encrypt}(pk, M'; r' = H_1(R' \| M'))$ . The idea of this proof is that it should be hard for an attacker to construct such a $C_1$ unless she has previously called the hash function $H_1$ on input $(R', M')$ . If she has called the hash function to produce this portion of the ciphertext, then she already knows those values and the decryption oracle provides her with no additional information she didn’t already have. (Alternatively, if she didÂ not call the hash function, then her probability of making a valid $C_1$ should be extremely low.)

Of course, this is only one strategy available to the attacker. She could also maul an existing ciphertext like $C^* = (C_1^*, C_2^*)$ . In this case her strategy is twofold: she can tamper with the first portion of the ciphertext and/or she can tamper with the second. But it’s easy to see that this will tend to break some portion of the decryption checks:

If she tampers with any bit of $C_2^*$ , she will change the recovered message into a new value that we can call $M''$ . However this will in turn (with overwhelming probability) cause the decryptor to recover very different random coins $r” \leftarrow H_1(R’ \| M”)$ than were used in the original construction of $C_1^*$ , and thus decryption check on that piece will probably fail.
If she tampers with any bit of $C_1^*$ , the decryption check $C_1^* == {\sf Encrypt}(pk, M’; r’) ought not to pass, and decryption will just produce an error.
She might try to tamper with both parts of the ciphertext, of course. But this would seem even more challenging.

The problem with the exercise above is that none of this constitutes aÂ proof that the approach works. There is an awful lot of should and probably in this argument, and none of this ought to make you very happy. A rough sketch of the proof for an F-O scheme can be found here. (I warn you that it’s probably got some bugs in it, and I’m offering it mainly as an intuition.)

The F-O scheme has many variants. A slightly different and much more formal treatment by Hofheinz and Kiltz can be found here, and deals with some other requirements on the underlying CPA-secure scheme.

To be continued…

So far in this discussion we’ve covered two basic techniques — both at a very superficial level — that achieve CCA2 security under the ridiculously strong assumption that random oracles exist. Unfortunately, they don’t. This motivates the need for better approaches that don’t require random oracles at all.

There are a couple of those that, sadly, nobody uses. Those will have to wait until the next post.

Was the Efail disclosure horribly screwed up?

TL;DR. No. Or keep reading if you want.

On Monday a team of researchers from MÃ¼nster, RUB and NXP disclosedÂ serious cryptographic vulnerabilitiesÂ in a number of encrypted email clients. The flaws, which go by the cute vulnerability name of “Efail”, potentially allow an attacker to decrypt S/MIME or PGP-encrypted email with only minimal user interaction.

By the standards of cryptographic vulnerabilities, this is about as bad as things get. In short: if an attacker can intercept and alter an encrypted email — say, by sending you a new (altered) copy, or modifying a copy stored on your mail server — they can cause many GUI-based email clients to send the full plaintext of the email to an attacker controlled-server. Even worse, most of the basic problems that cause this flaw have been known for years, and yet remain in clients.

The big (and largely under-reported) story of EFail is the way it affects S/MIME. That “corporate” email protocol is simultaneously (1) hated by the general crypto community because it’s awful and has a slash in its name, and yetÂ (2) is probably the most widely-used email encryption protocol in the corporate world. The table at the right — excerpted from the paper — gives you a flavor of how Efail affects S/MIME clients. TL;DR it affects them very badly.

EfailÂ also happens to affect a smaller, but non-trivial number of OpenPGP-compatible clients. As one might expect (if one has spent time around PGP-loving folks) the disclosure of these vulnerabilities has created something of a backlash on HN, and among people who make and love OpenPGP clients. Mostly for reasons that aren’t very defensible.

So rather than write about fun things — like the creation of CFB and CBC gadgets — today, I’m going to write about something much less exciting: the problem ofÂ vulnerabilityÂ disclosure in ecosystems like PGP. And how bad reactions to disclosure can hurt us all.

How Efail was disclosed to the PGP community

Putting together a comprehensive timeline of the Efail disclosure process would probably be a boring, time-intensive project. Fortunately Thomas Ptacek loves boring and time-intensive projects, and has alreadyÂ done thisÂ for us.

Briefly, the first Efail disclosures to vendors beganÂ last October, more than 200 days prior to the agreed publication date. The authors notified a large number of vulnerable PGP GUI clients, and also notified the GnuPG project (on which many of these projects depend) by February at the latest. From what I can tell every major vendor agreed to make some kind of patch. GnuPG decided that it wasn’t their fault, and basically stopped corresponding.

All parties agreedÂ not to publicly discuss the vulnerability until an agreed date in April, which was later pushed back to May 15. The researchers also notified the EFF and some journalists under embargo, but none of them leaked anything. On May 14 someone dumped the bug onto a mailing list. So the EFF posted a notice about the vulnerability (which we’ll discuss a bit more below), and the researchers put up a website. That’s pretty much the whole story.

There are three basic accusations going around about the Efail disclosure. They can be summarized as (1) maintaining embargoes in coordinated disclosures is really hard, (2) the EFF disclosure “unfairly” made this sound like a serious vulnerability “when it isn’t”, and (3) everything was already patched anyway so what’s the big deal.

Disclosures are hard; particularly coordinated ones

I’ve been involved in two disclosures of flaws in open encryption protocols. (Both were TLS issues.) Each one poses an impossible dilemma. You need to simultaneously (a) make sure every vendor has as much advance notice as possible, so they can patch their software. But at the same timeÂ (b) you need to avoid tellingÂ literallyÂ anyone, because nothing on the Internet stays secret. At some point you’ll notify some FOSS project that uses an open development mailing list or ticket server,Â and the whole problem will leak out into the open.

Disclosing bugs that affect PGP is particularly fraught. That’s because there’s no such thing as “PGP”. What we have instead is a large and distributed community that revolves around the OpenPGP protocol. The pillar of this community is theÂ GnuPG project, which maintains the core GnuPG tool and libraries that many clients rely on. Then there are a variety of niche GUI-based clients and email plugin projects. Finally, there are commercial vendors like Apple and Microsoft. (Who are mostly involved in the S/MIME side of things, and may reluctantly allow PGP plugins.)

Then, of course there are thousands of end-users, who will generally fail to update their software unless something really bad and newsworthy happens.

The obvious solution to the disclosure problem to use a staged disclosure. You notify the big commercial vendors first, since that’s where most of the affected users are.Â Then you work your way down the “long tail” of open source projects, knowing that inevitably the embargo could break and everyone will have to patch in a hurry. And you keep in mind thatÂ no matter what happens, everyone will blame you for screwing up the disclosure.

For the PGP issues in Efail, the big client vendors are Mozilla (Thunderbird), Microsoft (Outlook) and maybe Apple (Mail). The very next obvious choice would be to patch the GnuPG tool so that it no longer spits out unauthenticated plaintext, which is the root of many of the problems in Efail.

The Efail team appears to have pursued exactly this approach for the client-side vulnerabilities. Sadly, the GnuPG team made the decisionÂ that it’s not their job to pre-emptively address problems that they view as ‘clients misusing the GnuPG API’ (my paraphrase), even when that misuse appears to be rampant across many of the clients that use their tool. And so the most obvious fix for one part of the problem was not available.

This is probably the most unfortunate part of the Efail story, because in this case GnuPG is very much at fault. Their API does something that directly violatesÂ cryptographic best practicesÂ — namely, releasing unauthenticated plaintext prior to producing an error message. And while this could be understood as a reasonable API design at design time,Â continuing to support this API even as clients routinely misuse it has now led to flaws across the ecosystem. The refusal of GnuPG to take a leadership role in preemptively safeguarding these vulnerabilities both increases the difficulty of disclosing these flaws, and increases the probability of future issues.

So what went wrong with the Efail disclosure?

Despite what you may have heard, given the complexity of this disclosure, very little went wrong. The main issues people have raised seem to have to do with the contents of an EFF post. And with some really bad communications from Robert J. Hansen at the Enigmail (and GnuPG) project.

The EFF post.Â The Efail researchers chose to use the Electronic Frontier Foundation as their main source for announcing the existence of the vulnerability to the privacy community. This hardly seems unreasonable, because the EFF is generally considered a trusted broker, and speaks to the right community (at least here in the US).

The EFF post doesn’t give many details, nor does it give a list of affected (or patched) clients. It does give two pretty mild recommendations:

Temporarily disable or uninstall your existing clients until you’ve checked that they’re patched.
Maybe consider using a more modern cryptosystem like Signal, at least until you know that your PGP client is safe again.

This naturally led to a huge freakout by many in the PGP community. Some folks, including vendors, have misrepresented the EFF post as essentially pushing people to “permanently” uninstall PGP, which will “put lives at risk” because presumably these users (whose lives are at risk, remember) will immediately fall back to sending incriminating information via plaintext emails — rather than temporarily switching their communications to one of several modern, well-studiedÂ secure messengers, or just not emailing for a few hours.

In case you think I’m exaggerating about this, here’s one reaction from ProtonMail:

The most reasonable criticism I’ve heard of the EFF post is that it doesn’t give many details about which clients are patched, and which are vulnerable. This could presumably give someone the impression that this vulnerability is still present in their email client, and thus would cause them to feel less than secure in using it.

I have to be honest that to me that sounds likeÂ a really good outcome.Â The problem with Efail is that it doesn’t matter if your client is secure. The Efail vulnerability could affect you ifÂ even a single one of your communication partners is using an insecure client.

So needless to say I’m not very sympathetic to the reaction around the EFF post. If you can’t be sure whether your client is secure, you probably should feel insecure.

Bad communications from GnuPG and Enigmail. OnÂ the date of the disclosure, anyone looking for accurate information about security from two major projects — GnuPG and Enigmail — would not have been able to find it.

They wouldn’t have found it because developers fromÂ both Enigmail and GnuPGÂ were on mailing lists and Twitter claiming that they had never heard of Efail, and hadn’t been notified by the researchers. Needless to say, these allegations took off around the Internet, sometimesÂ in place of real information that could have helped users (like, whether either project had patched.)

It goes without saying that neither allegation was actually true. In fact, both project members soon checked with their fellow developers (and their memories) and found out that they’d both been given months of notice by the researchers, and that Enigmail had even developed a patch. (However, it turned out that even this patch may notÂ perfectly address the issue, and the community is still working to figure out exactly what still needs to be done.)

This is an understandable mistake, perhaps. But it sure is a bad one.

PGP is bad technology and it’s making a bad community

Now that I’ve made it clear that neither the researchers nor the EFF is out to get the PGP community, let me put on my mask and horns and tell you whyÂ someone should be.

I’ve written extensively about PGP on this blog, but in the past I’ve written mostly from a technical point of view about the problems with PGP. But what’s really problematic about PGP is not just the cryptography; it’s the story it tells about path dependence and how software communities work.

The fact of the matter is that OpenPGP is not really a cryptography project. That is, it’s not held together by cryptography.Â It’s held together by backwards-compatibility and (increasingly) a kind of an obsession with the idea of PGP as an end in and of itself, rather than as a means toÂ actually make end-users more secure.

Let’s face it, as a protocol, PGP/OpenPGP is just not what we’d develop if we started over today. It was formed over the years out of mostly experimental parts, which were in turn replaced, bandaged and repaired — and then worked into numerous implementations, which all had to be insanely flexible and yet compatible with one another. The result is bad, and most of the software implementing it is worse. It’s the equivalent of a beloved antique sports car, where the electrical system is totally shot, but it still drives. You know, the kind of car where the owner has to install a hand-switch so he can turn the reverse lights on manually whenever he wants to pull out of a parking space.

If PGP went away, I estimate it would take the security community less than a year to entirely replace (the key bits of) the standard with something much better and modern. It would have modern crypto and authentication, and maybe even extensions for future post-quantum future security. It would be simple.Â Many bright new people would get involved to help write the inevitable Rust, Go and Javascript clients and libraries.

Unfortunately for us all, (Open)PGP does exist. And that means that even fancy greenfield email projects feel like they need to support OpenPGP, or at least some subset of it. This in turnÂ perpetuates the PGP myth, and causes other clients to use it. And as a direct result, even if some clients re-implement OpenPGP from scratch, other clients will end up using tools like GnuPG which will support unauthenticated encryption with bad APIs. And the cycle will go round and around, like a spaceship stuck near the event horizon of a black hole.

And as the standard perpetuates itself, largely for the sake of being a standard, it will fail to attract new security people. It will turn away exactly the type of people who should be working on these tools.Â Those people will go off and build encryption systems in a totally different area, or they’ll get into cryptocurrency. And — with some exceptions —Â the people who work in the community will increasingly work in that community because they’re supporting PGP, and not because they’re trying to seek out the best security technologies for their users. And the serious (email) users of PGP will be using it because they like theÂ idea of using PGP better than they like using an actual, secure email standard.

And as things get worse, and fail to develop, people who work on it will become more dogmatic about its importance, because it’s something threatened and not a real security protocol that anyone’s using. To me that’s where PGP is going today, and that is why the community has such a hard time motivating itself to take these vulnerabilities seriously, and instead reacts defensively.

Maybe that’s a random, depressing way to end a post. But that’s the story I see in OpenPGP. And it makes me really sad.

Trusted by the Best

Powerful Features

Community

Get Started with WordPress

It’s Easy As…

Main Navigation

Build a website, build a movement.

Whatever you want to create, share, or sell, weâll help you do it right here.

Free to start, with room to grow.

Whether itâs a website, online store, portfolio, or blog, our plans scale with your dreams. All you need is an idea and an internet connection.

Blogger

$3

Personal

$5

Premium

$8

Business

$25

eCommerce

$45

What can you do on WordPress.com?

WordPress.com gives you everything you need to create anything you want. Itâs flexible, secure, and powerful, just like you want your business to be.

Build a fan base.

Open a store.

Start a blog.

Design a portfolio.

Engineering happiness.

Youâre in good company.

You can. You will. Weâll help.

Bottom Navigation Links

Bottom Navigation Menu

Main Navigation

Build a website, build a movement.

Whatever you want to create, share, or sell, weâll help you do it right here.

Free to start, with room to grow.

Whether itâs a website, online store, portfolio, or blog, our plans scale with your dreams. All you need is an idea and an internet connection.

Blogger

$3

Personal

$5

Premium

$8

Business

$25

eCommerce

$45

What can you do on WordPress.com?

WordPress.com gives you everything you need to create anything you want. Itâs flexible, secure, and powerful, just like you want your business to be.

Build a fan base.

Open a store.

Start a blog.

Design a portfolio.

Engineering happiness.

Youâre in good company.

You can. You will. Weâll help.

Bottom Navigation Links

Bottom Navigation Menu

Search

Read our other blogs:

Create your new blog or website for free

Get Started

Do More

Community

Company F • T

Our Mission

The Technology

The Details

The People

Our Story

Bill of Rights

The 1st Freedom

The 2nd Freedom

The 3rd Freedom

The 4th Freedom

Code Reference

Themes

Plugins

REST API

WP-CLI

Block Editor

Whatever you want to create, share, or sell, weâll help you do it right here.

Whether itâs a website, online store, portfolio, or blog, our plans scale with your dreams. All you need is an idea and an internet connection.

^$3

^$5

^$8

^$25

^$45

WordPress.com gives you everything you need to create anything you want. Itâs flexible, secure, and powerful, just like you want your business to be.

Youâre in good company.

You can. You will. Weâll help.